Add DID rotation signature to 23 #795
Conversation
Signed-off-by: Sam Curren <telegramsam@gmail.com>
| @@ -325,6 +325,19 @@ The exchange response message is used to complete the exchange. This message is | |||
| "signature": "3dZWsuru7QAVFUCtTd0s7uc1peYEijx4eyt5... (bytes omitted)" | |||
| } | |||
| } | |||
| }, | |||
| "did_rotate~attach": { | |||
There was a problem hiding this comment.
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 :-).
There was a problem hiding this comment.
second item: it's a tilde, not a dash.
first item - maybe/probably? A topic for tomorrow.
There was a problem hiding this comment.
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.
| * 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. | ||
|
|
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Great wording, though this implies a stronger MUST requirement than we usually allow for a minor version change.
There was a problem hiding this comment.
The MUST is in the eye of the recipient. If they choose to reject a connection because its not included, then so be it.
There was a problem hiding this comment.
need more language - feels wrong (warren) to not have a MUST included.
There was a problem hiding this comment.
What about the request message? Is it some clarification needed in regards of the signature for the DID Doc attachment?
From #717:
Signatures were never needed in the Requests, and were added by mistake by... me. Does this address your confusion? (@TelegramSam @ #717 (comment))
- the request message not to be signed. For did:peer:1 dids it's still required to not break interop, but for all resolvable dids, the signed attachment SHOULD NOT be present (@TimoGlastra @ RFC 0023: Can we accept inline peer did without a signature? #717 (comment))
There was a problem hiding this comment.
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 😝
Co-authored-by: Ariel Gentile <gentilester@gmail.com> Signed-off-by: Sam Curren <telegramsam@gmail.com>
The signature in the response is used to prove ownership over the key used in the invitation. In the request message, the only key they could prove ownership of is the one for the DID presented in the message, and that is already proven by sending an authcrypted message, per standard practice. Am I correct here? |
|
Discussed WG 20231004. Needs to bump the version to 1.1 |
Signed-off-by: Sam Curren <telegramsam@gmail.com>
Fixes #717