Removal of OOB and DID Exchange information #73

TelegramSam · 2020-07-02T21:01:10Z

Given the move to zero round trip models, these items are not longer needed.
Signed-off-by: Sam Curren [email protected]

These items are not longer neededSigned-off-by: Sam Curren <[email protected]>

tplooker · 2020-07-02T22:41:04Z

LGTM, will await others review before deciding to merge

troyronda · 2020-07-06T22:23:28Z

connections.md




-#### OutOfBand Protocol
-
-Invitations are usually the first message passed between parties. They are passed out of band, such as in a QR code or a link that can either open in an app or in a browser containing getting started instructions.


Are the concepts in OOB invitations being moved elsewhere in the spec?

Sort of. The ability to pass a message as an attachment isn't needed under the proposed 0RTT model.

The OutOfBand protocol provides a common mechanism to correlate a "not DIDComm activity" to a DIDComm message. This concept isn't about 0RTT vs DID Exchange but rather about defining a common mechanism for this capability.

Scenario: Alice has received an “invitation” (not in a DIDComm message) from Bob which then triggers Alice to send a DIDComm message to Bob.

OutOfBand defines an invitation format, goal/goal code, versioning information, and enables correlation based on the invitation message ID to a subsequent DIDComm message thread.

By (not in a DIDComm message) I think you mean "Not in a DIDComm Encrypted message", but still in one of the standard formats in the spec? (example: URL/QR code, or another yet to be defined format?)

Invitation format: See the QR code PR for defined format. #74
Versioning Information: Only pertained to the handshake protocols, which are not needed given the presence of the from and from_prior headers.
Correlation based on message ID: Correlate with the message ID of the message sent.

Goal/Goal Code: There isn't currently a replacement for this, or actually for the 'I want to exchange DIDs for no declared reason'. I believe the answer to this is deeper and related to the discussion about the ux of a user accepting an invitation. I'm going to open an issue to discuss this particular topic.

I think we've lost a cheap and sensible way to create an OOB invitation with explicit didcomm parameters (eg. no public DID).... see my comments here: #33 (comment)

troyronda · 2020-07-06T23:23:06Z

connections.md

@@ -2,254 +2,7 @@

 A Connection is the practical application of a relationship in DID Communication. Having a connection means that each party in the relationship has a DID for the other parties, and parties can communicate securely using the keys and endpoints within each DID Document.

-In order to establish a new connection, we use the OutOfBand Protocol and the DID Exchange Protocol.
+In order to establish a new connection, Simply exchange a new message between parties. Knowing the DID of the other parties does not indicate any level of trust. Using the connection to establish a foundation of trust is the next step.


In order to establish a new connection

At what point is the connection considered established by each party? Is it when the party receives a message back from the other party? (does the act of sending a message to a new DID constitute a pending connection until a message is returned?)

This is a great question. I've been spending some time considering our mental models around connections. More on this to come.

More thoughts on this, after discussion in both the Aries WG call and the DIDComm WG call today.

The historical context of 'established' is very binary: a connection is either 'established' or it isn't. I believe the right answer is closer to this: When you receive a message from the other party, you know their information about how to contact you is accurate. When they reply to something you sent, you know your information about how to contact them is accurate.

troyronda · 2020-07-06T23:39:16Z

connections.md

-
-##### 1. Exchange Request
-
-The exchange request message is used to communicate the DID document of the _invitee_ to the _inviter_ using the provisional service information present in the _invitation_ message.


I assume this particular purpose of the DID Exchange Protocol is obsoleted by usage of initial-state.

I am wondering about the nuance of peer DIDs and initial-state after the connection is considered established. Should initial-state continue to be sent after that point?

I think yes, though I think initial-state might not be the right term for that.

If the parties have an implicit connection establishment model (on top of the 0RTT any message model), then perhaps they could choose to stop sending initial-state once established. Without knowledge that the other party has persisted then, yes, I guess they would have to include with every message.

Agree. How the further changes to a did:peer did are communicated to the various parties is something that the method will need to define. Perhaps deltas a communicated in a query param as well, and dropped upon confirmation of receipt.

troyronda · 2020-07-06T23:45:35Z

connections.md

-{
-  "@id": "5678876542345",
-  "@type": "https://didcomm.org/didexchange/2.0/request",
-  "~thread": { "pthid": "<id of invitation>" },


The correlation to invitations is a useful concept. I am generally curious how the invitation concept is moving around. (also above comment: https://github.com/decentralized-identity/didcomm-messaging/pull/73/files#r450510409)

answered in above comment. tldr; You can still correlate to the message ID that is passed.

@TelegramSam can you point to the verbiage that describes the field used to indicate the thread's ID?

It's not in the DIDComm JWM Profile

Submitted PR #102 to add threading

llorllale · 2020-07-07T11:08:00Z

I would first like to see the alternative in detail before actually removing this content.

troyronda · 2020-07-07T13:25:03Z

connections.md

@@ -2,254 +2,7 @@

 A Connection is the practical application of a relationship in DID Communication. Having a connection means that each party in the relationship has a DID for the other parties, and parties can communicate securely using the keys and endpoints within each DID Document.

-In order to establish a new connection, we use the OutOfBand Protocol and the DID Exchange Protocol.
+In order to establish a new connection, Simply exchange a new message between parties. Knowing the DID of the other parties does not indicate any level of trust. Using the connection to establish a foundation of trust is the next step.


I am also curious about scenarios where a sender wants an established connection prior to some action/message/protocol. In some cases, they may wish to confirm that the recipient is able to decrypt their messages; that the route is working; and that the recipient can respond with authenticated messages; (and authenticate the DID). For example, during issuance or (generally) authentication scenarios.

In essence, I am curious if there are any generic aspects of a more established connection that end up in the spec vs being left up to higher layer messages/protocols.

I think that decision is up to us - which components are so core that they need to be in the spec, and which are better left to higher layers? I consider this to be very unresolved as yet.

troyronda · 2020-07-13T21:26:35Z

connections.md

-
-The _inviter_ will then craft an exchange response using the newly updated or provisioned information.
-
-###### Request Errors


I am curious about the difference in errors originating from OOB/DID Exchange vs the DIDComm v2 model?

Can you pick an example to discuss?

If I were to generalize the thought: How do we differentiate between a protocol-layer errors vs lower-layer concerns that were previously in these pre-step connection protocols. As an example, an unsupported DID method happened to be used (or unsupported key type or unsupported endpoint, etc).

Of course there is also possibilities such as unsupported protocols (or versions), but these would be cases that could happen regardless.

I don't believe OOB has anything in the spec about any of the errors you mentioned. Those are certainly important to think about, but I don't think there is a difference there between OOB/DIDExchange and 0RTT.

woiue · 2020-08-04T14:00:25Z

@TelegramSam on the last didcomm wg call, people agreed to put OOB in its own section. People were also more in favour of naming _dc _oob. In terms of naming, while for us it is quite obvious we should also define what _dc or _oob stands for.

TelegramSam · 2020-08-10T17:26:27Z

Updated all those items in the other PR.

llorllale · 2020-08-25T14:32:48Z

connections.md

-* The [`~thread`](../../concepts/0008-message-id-and-threading/README.md#thread-object) decorator MUST be included:
-  * It MUST include the ID of the parent thread (`pthid`) such that the `request` can be correlated to the corresponding `invitation`. More on correlation [below](#correlating-requests-to-invitations).
-  * It MAY include the `thid` property. In doing so, implementations MUST set its value to that of `@id` on the same request message. In other words, the values of `@id` and `~thread.thid` MUST be equal.
-* The `label` attribute provides a suggested label for the DID being exchanged. This allows the user to tell multiple exchange requests apart. This is not a trusted attribute.


We're losing the label feature... what's the replacement?

It seems that was missing from the OOB PR when it was approved. I think the best replacement of the label in an OOB invitation would be in the form of a PR to out_of_band.md.

Discussed on today's call: we need to push in a PR to the OOB text to add the label

dhh1128 · 2020-08-28T18:54:34Z

+1 to merge from me

troyronda · 2020-08-31T19:15:34Z

For those that want to validate a connection is established prior to another action, we will still need a protocol to do so.

Related: #81

troyronda · 2020-08-31T21:53:21Z

Regarding the usage of a ping protocol to enable an explicit RT at connection establishment.

In addition to using an authenticated RT ping, the other aspect is to enable linking that ping to an OOB request (e.g., stating the parent thread). This enables the Party to (A) know to respond to the ping; and (B) tie together the authenticated messages to an initial OOB action.

llorllale · 2020-08-31T21:58:31Z

Regarding the usage of a ping protocol to enable an explicit RT at connection establishment.

In addition to using an authenticated RT ping, the other aspect is to enable linking that ping to an OOB request (e.g., stating the parent thread). This enables the Party to (A) know to respond to the ping; and (B) tie together the authenticated messages to an initial OOB action.

See #95

troyronda · 2020-09-14T19:39:26Z

connections.md

-
-* The `@type` attribute is a required string value that denotes that the received message is an exchange request.
-* The [`~thread`](../../concepts/0008-message-id-and-threading/README.md#thread-object) decorator MUST be included:
-  * It MUST include the ID of the parent thread (`pthid`) such that the `request` can be correlated to the corresponding `invitation`. More on correlation [below](#correlating-requests-to-invitations).


parent thread will need to be defined elsewhere in the spec.

#95 (comment)

Removal of OOB and DID Exchange information

a51ba10

These items are not longer neededSigned-off-by: Sam Curren <[email protected]>

tplooker approved these changes Jul 2, 2020

View reviewed changes

kdenhartog approved these changes Jul 2, 2020

View reviewed changes

TelegramSam added the not yet ready This is not yet ready to be completed label Jul 6, 2020

troyronda reviewed Jul 6, 2020

View reviewed changes

troyronda reviewed Jul 7, 2020

View reviewed changes

troyronda reviewed Jul 13, 2020

View reviewed changes

troyronda mentioned this pull request Jul 21, 2020

What are the Essential Protocols that should be included in the DIDComm spec? #81

Closed

TelegramSam removed the not yet ready This is not yet ready to be completed label Aug 10, 2020

llorllale reviewed Aug 25, 2020

View reviewed changes

dhh1128 approved these changes Aug 28, 2020

View reviewed changes

llorllale approved these changes Aug 31, 2020

View reviewed changes

llorllale mentioned this pull request Aug 31, 2020

How to link a message to a context? (aka "threading") #95

Closed

troyronda reviewed Sep 14, 2020

View reviewed changes

tplooker approved these changes Sep 21, 2020

View reviewed changes

tplooker merged commit ce54c00 into decentralized-identity:master Sep 21, 2020

TelegramSam deleted the remove_connections branch September 28, 2020 17:09




		#### OutOfBand Protocol

		Invitations are usually the first message passed between parties. They are passed out of band, such as in a QR code or a link that can either open in an app or in a browser containing getting started instructions.


		##### 1. Exchange Request

		The exchange request message is used to communicate the DID document of the _invitee_ to the _inviter_ using the provisional service information present in the _invitation_ message.


		The _inviter_ will then craft an exchange response using the newly updated or provisioned information.

		###### Request Errors

Removal of OOB and DID Exchange information #73

Removal of OOB and DID Exchange information #73

Conversation

TelegramSam commented Jul 2, 2020

tplooker commented Jul 2, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

troyronda Jul 6, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

troyronda Jul 6, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

troyronda Jul 6, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

llorllale commented Jul 7, 2020

troyronda Jul 7, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

woiue commented Aug 4, 2020

TelegramSam commented Aug 10, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dhh1128 commented Aug 28, 2020

troyronda commented Aug 31, 2020

troyronda commented Aug 31, 2020

llorllale commented Aug 31, 2020

troyronda Sep 14, 2020 • edited Loading

Choose a reason for hiding this comment

troyronda Jul 6, 2020 •

edited

Loading

troyronda Jul 6, 2020 •

edited

Loading

troyronda Jul 6, 2020 •

edited

Loading

troyronda Jul 7, 2020 •

edited

Loading

troyronda Sep 14, 2020 •

edited

Loading