hyperledger / aries-rfcs

Hyperledger Aries is infrastructure for blockchain-rooted, peer-to-peer interactions
https://hyperledger.github.io/aries-rfcs/
Apache License 2.0
326 stars 217 forks source link

RFC 0036 and 0037: need to explain why payloads aren't shown #168

Closed dhh1128 closed 5 years ago

dhh1128 commented 5 years ago

Per a discussion on the Aug 7 2019 community call...

The RFCs show messages, but omit detail about specific payloads (the actual content of credentials and presentations). The reason is deliberate (allow evolution of credential formats independent of the protocol that exchanges them). However, the RFCs don't explain this. We need verbiage in the RFCs to clarify.

We probably also need links in the RFCs to help people find the format of the payloads, even if the RFCs themselves don't show the data.

dhh1128 commented 5 years ago

@llorllale @TelegramSam @kdenhartog

kdenhartog commented 5 years ago

As shown in the issue title this affects both RFC 0036 and 0037 and we should delay the two week waiting period until this issue is resolved.

swcurran commented 5 years ago

Did anyone volunteer for this one? Glad to take it if not. Grab it back from me if you volunteered.

@dhh1128 @kdenhartog

swcurran commented 5 years ago

@dhh1128 @llorllale

Maybe I missed the point of this issue - I thought this was about the contents of the attachments and notably the Indy format. In each of the message descriptions, there is a description of the contents of the attachment and a link to into the indy-sdk code to where the related call is defined, and the data structures are documented.

Is that not sufficient, are the links incorrect, or is the issue being raised for some other purpose?

Example: request-presentation:

For Indy, the attachment contains data from libindy about the presentation request, base64 encoded. The following JSON is an example of the libindy-request-presentation-0 attachment content. For more information see the Libindy API. https://github.com/hyperledger/indy-sdk/blob/57dcdae74164d1c7aa06f2cccecaae121cefac25/libindy/src/api/anoncreds.rs#L1214

llorllale commented 5 years ago

@swcurran the goal here is to explain why the RFC deliberately stops short of specifying the contents of the payloads and instead opts to leave it up to implementations.

swcurran commented 5 years ago

I listened to the call and get the context better. What was throwing me off was saying this wasn't covered and the point about providing a connection to the implementation. That is called out in the already in the RFC, but I'll make it even more explicit.

dhh1128 commented 5 years ago

Resolved by PR #173