DID Rotate Protocol #794

TelegramSam · 2023-08-29T15:02:34Z

No description provided.

Signed-off-by: Sam Curren <[email protected]>

genaris · 2023-08-30T02:30:29Z

features/0794-did-rotate/README.md

+{
+    "@id": "123456780",
+    "@type": "https://didcomm.org/did-rotate/1.0/ack",
+    "to_did": "did:example:newdid",


Is it needed to repeat the to_did field to confirm the reception of it, or should this message follow the convention including status and thread id? For example:

"status": "OK", "~thread": { "thid": "rotate-did-message-id", }

Good topic for discussion in the Aries WG call. I included it as a bit of redundant info, but maybe it shouldn't be.

using only thid avoids error conditions where the returned to_did doesn't match the one sent in the rotate message.

fixed in next commit

TelegramSam · 2023-08-30T14:35:08Z

note about reasonable time for observing party

TelegramSam · 2023-08-30T14:35:49Z

notes about stored messages and state, and what should be updated.

TelegramSam · 2023-08-30T14:37:03Z

discussed WG 20230830. ok to merge after discussed changes.

genaris · 2023-08-30T16:57:57Z

I'm sorry if you've discussed this today and I wasn't paying attention but I noticed from a Discord message from @swcurran something that seems to me a very good idea: to be able to set to_did field to a null value in order to terminate the connection (pretty much the same as supported natively DIDComm V2).

I think this may add a little bit of complexity, but certainly would give to this protocol more value and solve an interesting use-case in an elegant way.

swcurran · 2023-08-30T20:09:05Z

Thanks for raising that @genaris — I forgot to raise it. I think it is an excellent idea. The Discord use case was for ending a mediator connection, but there are many other use cases, I’m sure.

Signed-off-by: Sam Curren <[email protected]>

features/0794-did-rotate/README.md

swcurran · 2023-09-01T11:08:12Z

features/0794-did-rotate/README.md

@@ -19,6 +19,10 @@ This protocol is only applicable to DIDComm v1 - in DIDComm v2 use the more effi
 This mechanism allows a party in a relationship to change the DID in use for the relationship. This may be used to switch DID methods,
 but also to switch to a new DID within the same DID method. Inspired by (but different from) the DID rotation feature of the DIDComm Messaging (DIDComm v2) spec.


“new DID within the same DID method” to “new DID within the same DID method, such as to update the mediator relationship in the DIDDoc.”

I think it would be helpful to include that example.

Super minor, and not necessary, but I realize there are other motivators for adding/using this protocol, and perhaps a list is needed:

change mediators

change the key in an non-updatable DID method.

hanging up

Switch from a deprecated DID Method, such as unqualified DIDs or did:peer numalogos 1 and 2/3 to did:peer:4

swcurran · 2023-09-01T11:15:08Z

features/0794-did-rotate/README.md

@@ -19,6 +19,10 @@ This protocol is only applicable to DIDComm v1 - in DIDComm v2 use the more effi
 This mechanism allows a party in a relationship to change the DID in use for the relationship. This may be used to switch DID methods,
 but also to switch to a new DID within the same DID method. Inspired by (but different from) the DID rotation feature of the DIDComm Messaging (DIDComm v2) spec.

+## Implications for Software Implementations
+
+This protocol enables the identifiers used in a relationship to change. Implementations will need to consider how data related to the relationship is managed. If the relationship DIDs are used as identifiers, those identifiers may need to be updated during the rotation to maintain data integrity.


I think this comment is pretty subtle, and useful only for those “deep in the know”. I’m not sure this is any better, so take this with a grain of salt...

Implementations will need to consider how data (public keys, DIDs and the ID for the relationship) related to the relationship is managed. If the relationship DIDs are used as identifiers, those identifiers may need to be updated during the rotation to maintain data integrity. For example, both parties might have to retain and be able to use as identifiers for the relationship the existing DID and the rotated to DID, and their related keys for a period of time until the rotation is complete.

swcurran · 2023-09-01T11:18:33Z

features/0794-did-rotate/README.md

@@ -62,13 +66,17 @@ Message Type URI: https://didcomm.org/did-rotate/1.0/ack

 This message is still sent to the prior DID to acknowledge the receipt of the rotation. Following messages will be sent to the new DID.

-`to_did`: The new DID to be used to identify the **rotating_party**
+In order to correctly process out of order messages, the The **observing_party** may choose to receive messages from the old did for a reasonable period. This allows messages sent before rotation but received after rotation in the case of out of order message delivery.


Consistency — “old did” —> “old DID"

swcurran · 2023-09-01T11:21:12Z

features/0794-did-rotate/README.md

@@ -62,13 +66,17 @@ Message Type URI: https://didcomm.org/did-rotate/1.0/ack

 This message is still sent to the prior DID to acknowledge the receipt of the rotation. Following messages will be sent to the new DID.

-`to_did`: The new DID to be used to identify the **rotating_party**


For this ACK and Problem Report section it is typical to talk about the two messages being “adopted” by the ACK and Report Problem messages, to include a link and to ensure that the usage is consistent. I didn’t check on the consistency of use, but I’m guessing it was done :-).

swcurran · 2023-09-01T11:25:55Z

features/0794-did-rotate/README.md

+
+The **rotating_party** is expected to receive messages on both the existing and new DIDs and their associated keys for a reasonable period that MUST extend at least until the following `ack` message has been received.
+
+This message MUST be sent using authcrypt or as a signed message in order to establish the provenance of the new DID. Proper provenance prevents injection attacks that seek to take over a relationship. Any rotate message received without being authcrypted or signed MUST be discarded and not processed.


I would add something like so that readers unfamiliar with the DIDComm message handling will not go down a rabbit hole of trying to figure out if a message is AuthCrypt or not: “In Aries implementations, messages sent in the context of an existing relationship are by default sent using authcrypt.”

swcurran · 2023-09-01T11:27:12Z

Looks good to me. A few suggestions, but very minor — I won’t be upset if they aren’t made. Let me know when you have looked at them to your satisfaction, and I’ll approve.

Nice work!

features/0794-did-rotate/README.md

Co-authored-by: Daniel Bluhm <[email protected]> Signed-off-by: Sam Curren <[email protected]>

Signed-off-by: Sam Curren <[email protected]>

dbluhm · 2023-09-12T17:04:49Z

In a quick attempt to feel out any unexpected gotchas, I'm going to take a quick pass at an implementation of the proposed protocol. I'll report back with my findings.

Signed-off-by: Sam Curren <[email protected]>

genaris · 2023-09-19T18:16:32Z

features/0794-did-rotate/README.md

+## Motivation
+
+This mechanism allows a party in a relationship to change the DID they use to identify themselves in that relationship. This may be used to switch DID methods,
+but also to switch to a new DID within the same DID method. For non-updatable DID methods, this allows updating DID Doc attributes such as service endpoints. Inspired by (but different from) the DID rotation feature of the DIDComm Messaging (DIDComm v2) spec.


I think updating DID Doc attributes for non-resolvable DIDs would need to also attach the DID Document, like we do in DID Exchange protocol.

Do you think we can add an attachment for those cases to allow a broader range of use cases of this protocol, or limit it to those DIDs that are publicly resolvable or embed the DID Document on its identifier?

Given the timing of this and the availability/desirability of did:peer:4, that we should not add this. We don’t want implementations using either unqualified DIDs or did:peer:1, which are the only options AFAIK that would need this. We could add a note about this, but I don’t think we should add the attachment option.

I'm not sure I understand the question. Let's discuss in the Aries WG.

per discussion in WG 20230920: Would prefer not to add support in favor of did:peer:4, but willing to add if this presents a significant hurdle for the community using did:peer:1.

swcurran

Discussed and agreed to be merged at Aries Working Group Call 2023.12.06.

TelegramSam added 2 commits August 29, 2023 09:02

DID Rotate Protocol

9c41657

Signed-off-by: Sam Curren <[email protected]>

number correction

5cb5473

Signed-off-by: Sam Curren <[email protected]>

genaris reviewed Aug 30, 2023

View reviewed changes

TelegramSam added 2 commits August 31, 2023 12:15

PR suggested fixes

3eaa780

Signed-off-by: Sam Curren <[email protected]>

hangup message

ba6f940

Signed-off-by: Sam Curren <[email protected]>

swcurran reviewed Sep 1, 2023

View reviewed changes

features/0794-did-rotate/README.md Outdated Show resolved Hide resolved

swcurran reviewed Sep 1, 2023

View reviewed changes

dbluhm reviewed Sep 5, 2023

View reviewed changes

features/0794-did-rotate/README.md Outdated Show resolved Hide resolved

TelegramSam and others added 2 commits September 6, 2023 07:58

Update features/0794-did-rotate/README.md

ef543ef

Co-authored-by: Daniel Bluhm <[email protected]> Signed-off-by: Sam Curren <[email protected]>

Fixes per Stephen's suggestions

30eb05f

Signed-off-by: Sam Curren <[email protected]>

dbluhm mentioned this pull request Sep 15, 2023

WIP: DID Rotate Protocol openwallet-foundation/acapy#2494

Closed

Addition of a Doc Unsupported error

d9fe480

Signed-off-by: Sam Curren <[email protected]>

dbluhm approved these changes Sep 15, 2023

View reviewed changes

genaris reviewed Sep 19, 2023

View reviewed changes

swcurran approved these changes Sep 20, 2023

View reviewed changes

TelegramSam and others added 2 commits November 28, 2023 21:19

Merge branch 'main' into did_rotate

0aa4380

Merge branch 'main' into did_rotate

08975c1

swcurran approved these changes Dec 6, 2023

View reviewed changes

swcurran merged commit 5300d2c into hyperledger:main Dec 6, 2023
1 check passed

TelegramSam deleted the did_rotate branch December 12, 2023 22:45

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

DID Rotate Protocol #794

DID Rotate Protocol #794

TelegramSam commented Aug 29, 2023

genaris Aug 30, 2023

TelegramSam Aug 30, 2023

TelegramSam Aug 30, 2023

TelegramSam Aug 31, 2023

TelegramSam commented Aug 30, 2023

TelegramSam commented Aug 30, 2023

TelegramSam commented Aug 30, 2023

genaris commented Aug 30, 2023

swcurran commented Aug 30, 2023

swcurran Sep 1, 2023

swcurran Sep 20, 2023

swcurran Sep 1, 2023

swcurran Sep 1, 2023

swcurran Sep 1, 2023

TelegramSam Sep 7, 2023

swcurran Sep 1, 2023

swcurran commented Sep 1, 2023

dbluhm commented Sep 12, 2023

genaris Sep 19, 2023

swcurran Sep 20, 2023

TelegramSam Sep 20, 2023

TelegramSam Sep 20, 2023

swcurran left a comment

		@@ -19,6 +19,10 @@ This protocol is only applicable to DIDComm v1 - in DIDComm v2 use the more effi
		This mechanism allows a party in a relationship to change the DID in use for the relationship. This may be used to switch DID methods,
		but also to switch to a new DID within the same DID method. Inspired by (but different from) the DID rotation feature of the DIDComm Messaging (DIDComm v2) spec.

		@@ -62,13 +66,17 @@ Message Type URI: https://didcomm.org/did-rotate/1.0/ack

		This message is still sent to the prior DID to acknowledge the receipt of the rotation. Following messages will be sent to the new DID.

		`to_did`: The new DID to be used to identify the rotating_party


		The rotating_party is expected to receive messages on both the existing and new DIDs and their associated keys for a reasonable period that MUST extend at least until the following `ack` message has been received.

		This message MUST be sent using authcrypt or as a signed message in order to establish the provenance of the new DID. Proper provenance prevents injection attacks that seek to take over a relationship. Any rotate message received without being authcrypted or signed MUST be discarded and not processed.

DID Rotate Protocol #794

DID Rotate Protocol #794

Conversation

TelegramSam commented Aug 29, 2023

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

TelegramSam commented Aug 30, 2023

TelegramSam commented Aug 30, 2023

TelegramSam commented Aug 30, 2023

genaris commented Aug 30, 2023

swcurran commented Aug 30, 2023

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

Choose a reason for hiding this comment

swcurran commented Sep 1, 2023

dbluhm commented Sep 12, 2023

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

swcurran left a comment

Choose a reason for hiding this comment