propose HIPE: DIDComm explainer #98
Conversation
Signed-off-by: Daniel Hardman <[email protected]>
Signed-off-by: Daniel Hardman <[email protected]>
|
I feel like this is ready for FCP. It doesn't answer all questions but is a fine foundation that can be amended through future HIPEs and PRs. |
| A typical DIDComm interaction works like this: | ||
|
|
||
| <blockquote> | ||
| Imagine Alice wants to negotiate with Bob to sell something online, and |
There was a problem hiding this comment.
I suggest that in this example, we use a protocol that is in process. Perhaps the tic-tac-toe one. That way at the end we can point to it for details of how a protocol gets specified.
| * DIDComm doesn't always involve turn-taking and request-response. | ||
| * DIDComm interactions can involve more than 2 parties, and the parties are | ||
| not always individuals. | ||
| * DIDComm may include formats other than JSON. |
There was a problem hiding this comment.
I'm not sure why this is needed at this point (it seems several levels of detail below this overview). Further, even if the data format is not JSON, it's delivered embedded in JSON. As such, I don't think as stated, this is correct.
Signed-off-by: Daniel Hardman <[email protected]>
|
This PR has been superseded by Aries RFC 0005 (https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0005-didcomm) |
No description provided.