Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add DID rotation signature to 23 #795

Merged
merged 4 commits into from
Dec 6, 2023
Merged

Add DID rotation signature to 23 #795

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
99869a2
Add DID rotation signature to 23
TelegramSam Sep 13, 2023
63d6071
Update features/0023-did-exchange/README.md
TelegramSam Sep 20, 2023
b58c91d
Added version number bump for optional attribute
TelegramSam Oct 24, 2023
e654f34
Merge branch 'main' into 23_optional_signed_did
swcurran Dec 6, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 21 additions & 2 deletions features/0023-did-exchange/README.md
View file
Open in desktop
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe is it a good opportunity to remove the double of @swcurran from this list? Not sure if it is the first one or the second one 😝

Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down Expand Up @@ -325,6 +330,19 @@ The exchange response message is used to complete the exchange. This message is
"signature": "3dZWsuru7QAVFUCtTd0s7uc1peYEijx4eyt5... (bytes omitted)"
}
}
},
"did_rotate~attach": {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two questions to consider — more to know why you did it this way then to propose changes.

  • Should this be a change to the protocol version to 1.1?
    • It is a new item, so I wanted to check to see if you think there should be a version bump.
  • Why the “_” and “-“ in the same item?
    • I see it in the did_doc-attach, so assume that is the reason, but thought I would ask :-).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

second item: it's a tilde, not a dash.
first item - maybe/probably? A topic for tomorrow.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doh! Sorry about that — it flashed through my head that the attach was a decorator, but didn’t stick, and not when I was looking at the item name :-).

That makes it easier for this to be a no version change. The guidance is to put a decorator on it with this content vs. the must. Of course, any implementation can do what they think is appropriate — either including the ~attach decorator or not, ignoring or processing the decorator on receipt, and rejecting or not the connection if NOT included.

"mime-type": "text/string",
"data": {
"base64": "Qi5kaWRAQjpB",
"jws": {
"header": {
"kid": "did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th"
},
"protected": "eyJhbGciOiJFZERTQSIsImlhdCI6MTU4Mzg4... (bytes omitted)",
"signature": "3dZWsuru7QAVFUCtTd0s7uc1peYEijx4eyt5... (bytes omitted)"
}
}
}
}
```
Expand All @@ -337,8 +355,9 @@ 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.

Comment on lines +360 to 361
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should include that if a did is used in the response message that is different from the invitation, the did_rotate~attach MUST be present.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great wording, though this implies a stronger MUST requirement than we usually allow for a minor version change.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The MUST is in the eye of the recipient. If they choose to reject a connection because its not included, then so be it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

need more language - feels wrong (warren) to not have a MUST included.

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.

Expand All @@ -350,7 +369,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

Expand Down
Loading