propose HIPE: Introductions #110
Conversation
Signed-off-by: Daniel Hardman <daniel.hardman@gmail.com>
Signed-off-by: Daniel Hardman <daniel.hardman@gmail.com>
Signed-off-by: Daniel Hardman <daniel.hardman@gmail.com>
Signed-off-by: Daniel Hardman <daniel.hardman@gmail.com>
Signed-off-by: Daniel Hardman <daniel.hardman@gmail.com>
Signed-off-by: Daniel Hardman <daniel.hardman@gmail.com>
Signed-off-by: Daniel Hardman <daniel.hardman@gmail.com>
Signed-off-by: Daniel Hardman <daniel.hardman@gmail.com>
Signed-off-by: Daniel Hardman <daniel.hardman@gmail.com>
| begins the connection protocol, is also the final step in an | ||
| introduction. | ||
|
|
||
| Said differently, *the goal of the introduction protocol is to start the |
There was a problem hiding this comment.
Clarification is needed to define what the intended target relationship between the participants for a specific instance of an introduction. There are two possibilities that I see:
- Create a new relationship between Bob and Carol
- Create a new relationship between Bob, Carol and Alice
Arguably, a third relationship could be to add Bob to Carol and Alice's existing relationship, but I would argue that might be the connection protocol or (I think more likely) a new protocol that we've not defined. I would suggest not including it in this protocol.
Suggestion is to make it clear which type of target relationship is intended as you go through this. I'm not clear which you are talking about in the rest of the document.
| appear at first glance. The [Advanced Use Cases](#advanced-use-cases) | ||
| section later in the doc explores many variations. But the early part | ||
| of this document focuses on the simplest reading of the use case. | ||
|
|
There was a problem hiding this comment.
I think a mention of the danger of this protocol is needed. This is by definition a "man-in-the-middle" flow. Because the invitation flows to the introducer from the inviter to the invitee, there is a MITM, and I suspect that this protocol will be a target for exploitation. Later in the document, mitigations should be described.
| an introducee may not be able to (or may not want to) share a DIDComm | ||
| endpoint to facilitate the introduction. In such cases, the stripped-down | ||
| variant may be the right choice. See the [Advanced Use Cases](#advanced-use-cases) | ||
| section for more details. |
There was a problem hiding this comment.
Since this is covered in the Advanced Use Case section, I recommend it leaving it out of this section entirely. At most a one liner, something like "As covered in the Advanced Use Case section, the invitation is optional."
|
|
||
| ### States | ||
|
|
||
| In a successful introduction, the introducer state progresses from |
There was a problem hiding this comment.
Hmm...I see from the state diagram that proposals are sent to each invitee? I was under the impression from a first pass reading about the proposal that it would only go to one of the two, but leaves me a bit confused as to the overall flow. Does that mean that two invitations also flow to the invitees through the introducer?
Also confused by the "Skip Proposal" event, so a clarification of that might help. Found it later - might be worth flagging here.
| This message is not a member of the `introductions/1.0` message family; | ||
| it is not even adopted. It is part of the `connections/1.0` family, and | ||
| is no different from the message that two parties would generate when one | ||
| invites the other with no intermediary, except that: |
There was a problem hiding this comment.
I think that either this conveyance of the invitation needs to be a separate message from the connection-invitation. First, this is a DIDComm message, which I don't think is true of the connection-invitation. Wouldn't this be a forwarded invitation?
Second, I think there needs to be more information sent to add context beyond just the label. The label should be the same, but there should be a way to say "This is being sent based on an introduction from Alice". Maybe that's a change to the connection-invitation.
The latter context point may be based on my confusion on whether the introducee has already received a proposal and that the threading provides sufficient context.
| that needs SSI onboarding?] | ||
| * If the invitation is delivered over a DIDComm channel, it is unusual | ||
| in that it is from a party other than the one that owns the channel. | ||
|
|
There was a problem hiding this comment.
I suggest adding at this point that Alice could be malicious in establishing this relationship and modify the invitation so that the connection-request came to her (Alice) in order to establish a new relationship with Bob, with Alice masquerading as Carol. This HIPE should underline the importance of using a follow-up verifiable credentials mutual authentication by the participants.
I was playing with some attempts to prevent that, but can't see how. Anyone else see an approach?
My assessment of @kdenhartog's concern about MITM on the Connection Protocol HIPE leads to the same conclusion - attacks are possible, so post-connection authentication is always needed. This introduction protocol is somewhat different in that by definition, there is a man-in-the-middle, albeit a one that is known (trusted?) by both parties. The nice part of this protocol is that because all of the messages use DIDComm, other MITM attacks are (likely) eliminated.
|
|
||
| Some specific examples follow. | ||
|
|
||
| #### One introducee can't do DIDComm |
There was a problem hiding this comment.
I don't get this use case in the introduction protocol context. If Bob doesn't have a DIDComm capability then Alice doesn't have an existing DIDComm-based relationship to use for the introduction protocol. That would be addressed by Alice using the connection protocol to connect with Bob so he does have DIDComm capabilities.
| and may be appropriate in certain circumstances. Most should be self-explanatory, | ||
| but the `proposed` field deserves special comment. This tells whether the | ||
| described introducee has received a proposal of their own, or will be | ||
| introduced without that step. |
There was a problem hiding this comment.
I don't understand this example (why are we scheduling an MRI in an introduction?), nor the proposed field. A further explanation would be helpful.
| This example also adds the `nwise` field to the proposal. When `nwise` is | ||
| present and its value is `true`, the proposal is to establish an nwise | ||
| relationship in which the introducer participates, as opposed to a pairwise | ||
| relationship in which only the introducees participate. |
There was a problem hiding this comment.
I don't understand the implications of this. What changes when nwise is true? That would seem to require a lot to the protocol.
Signed-off-by: Daniel Hardman <daniel.hardman@gmail.com>
Signed-off-by: Daniel Hardman <daniel.hardman@gmail.com>
|
|
||
| ### Roles | ||
|
|
||
| There are three [TODO:do we want to support introducing more than 2 at a time?] |
There was a problem hiding this comment.
In AgentFramework we have the concept of a multi-party connection invitation, i.e I might be doing a presentation where I put a QR code at the end of the presentation for any attendees to connect with me after. Perhaps this should be a consideration in this protocol for multi-party introductions?
Signed-off-by: Daniel Hardman <daniel.hardman@gmail.com>
|
This has been superseded by Aries RFC 0028. |
Signed-off-by: Daniel Hardman daniel.hardman@gmail.com