From 99869a28c575379711070b52a4e4aa01578f9b66 Mon Sep 17 00:00:00 2001 From: Sam Curren Date: Tue, 12 Sep 2023 19:19:34 -0600 Subject: [PATCH 1/3] Add DID rotation signature to 23 Signed-off-by: Sam Curren --- features/0023-did-exchange/README.md | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/features/0023-did-exchange/README.md b/features/0023-did-exchange/README.md index 213b9621d..03bb56b9f 100644 --- a/features/0023-did-exchange/README.md +++ b/features/0023-did-exchange/README.md @@ -325,6 +325,19 @@ The exchange response message is used to complete the exchange. This message is "signature": "3dZWsuru7QAVFUCtTd0s7uc1peYEijx4eyt5... (bytes omitted)" } } + }, + "did_rotate~attach": { + "mime-type": "text/string", + "data": { + "base64": "Qi5kaWRAQjpB", + "jws": { + "header": { + "kid": "did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th" + }, + "protected": "eyJhbGciOiJFZERTQSIsImlhdCI6MTU4Mzg4... (bytes omitted)", + "signature": "3dZWsuru7QAVFUCtTd0s7uc1peYEijx4eyt5... (bytes omitted)" + } + } } } ``` @@ -339,6 +352,7 @@ The invitation's `recipientKeys` should be dedicated to envelopes authenticated * The `did_doc~attach` optional, contains the DID Doc associated with the `did`, if required. * If the `did` is resolvable (either an inline `peer:did` or a publicly resolvable DID), the `did_doc~attach` attribute should not be included. * If the DID is a `did:peer` identifier, the DIDDoc must be as outlined in [RFC 0627 Static Peer DIDs](../0627-static-peer-dids/README.md). +* The `did_rotate~attach` attribute is optional, but SHOULD be included if the `did` attribute is resolvable and the `did_doc~attach` is not included. The value is the Base64url encoded DID, and signed with the key used in the invitation. In addition to a new DID, the associated DID Doc might contain a new endpoint. This new DID and endpoint are to be used going forward in the relationship. @@ -350,7 +364,7 @@ When the message is sent, the _responder_ are now in the `response-sent` state. #### Response Processing -When the requester receives the `response` message, they will decrypt the authenticated envelope which confirms the source's authenticity. After decryption validation, they will update their wallet with the new information, and use that information in sending the `complete` message. +When the requester receives the `response` message, they will decrypt the authenticated envelope which confirms the source's authenticity. After decryption validation, the signature on the `did_doc~attach` or `did_rotate~attach` MUST be validated, if present. The key used in the signature MUST match the key used in the invitation. After attachment signature validation, they will update their wallet with the new information, and use that information in sending the `complete` message. #### Response Errors From 63d6071f293260c6c13a22b4d5b7b1942abc550c Mon Sep 17 00:00:00 2001 From: Sam Curren Date: Wed, 20 Sep 2023 07:47:48 -0600 Subject: [PATCH 2/3] Update features/0023-did-exchange/README.md Co-authored-by: Ariel Gentile Signed-off-by: Sam Curren --- features/0023-did-exchange/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/features/0023-did-exchange/README.md b/features/0023-did-exchange/README.md index 03bb56b9f..dbaed1946 100644 --- a/features/0023-did-exchange/README.md +++ b/features/0023-did-exchange/README.md @@ -350,7 +350,7 @@ The invitation's `recipientKeys` should be dedicated to envelopes authenticated * The `~thread` decorator MUST be included. It contains a `thid` reference to the `@id` of the request message. * The `did` attribute MUST be included. It denotes the DID in use by the responder. Note that this MAY NOT be the same DID used in the invitation. * The `did_doc~attach` optional, contains the DID Doc associated with the `did`, if required. - * If the `did` is resolvable (either an inline `peer:did` or a publicly resolvable DID), the `did_doc~attach` attribute should not be included. + * If the `did` is resolvable (either an inline `did:peer` or a publicly resolvable DID), the `did_doc~attach` attribute should not be included. * If the DID is a `did:peer` identifier, the DIDDoc must be as outlined in [RFC 0627 Static Peer DIDs](../0627-static-peer-dids/README.md). * The `did_rotate~attach` attribute is optional, but SHOULD be included if the `did` attribute is resolvable and the `did_doc~attach` is not included. The value is the Base64url encoded DID, and signed with the key used in the invitation. From b58c91d29615c04d2163c574fecc971eb63a2c65 Mon Sep 17 00:00:00 2001 From: Sam Curren Date: Tue, 24 Oct 2023 11:36:00 -0600 Subject: [PATCH 3/3] Added version number bump for optional attribute Signed-off-by: Sam Curren --- features/0023-did-exchange/README.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/features/0023-did-exchange/README.md b/features/0023-did-exchange/README.md index dbaed1946..358790855 100644 --- a/features/0023-did-exchange/README.md +++ b/features/0023-did-exchange/README.md @@ -16,6 +16,11 @@ This RFC describes the protocol to exchange DIDs between agents when establishin Aries agent developers want to create agents that are able to establish relationships with each other and exchange secure information using keys and endpoints in DID Documents. For this to happen there must be a clear protocol to exchange DIDs. +## Version Change Log + +### 1.1 - Signed Rotations without DID Documents +Added the optional `did_rotate~attach` attachment for provenance of rotation without an attached DID Document. + ## Tutorial We will explain how DIDs are exchanged, with the roles, states, and messages required.