what's new section #96
Conversation
Signed-off-by: Sam Curren <[email protected]>
guide/whatsnew.md
Outdated
|
|
||
| #### Use Peer DIDs (or other suitable DID method) in place of AnonCrypt | ||
|
|
||
| Anoncrypt was a method present in V1 that allowed a message to be encrypted to a recipient without involving the recipient keys. The ease of using Peer DIDs allows the sender to remain anonymous using the existing authenticated encryption method. The encryption properties are the same between the methods. Eliminating this option makes the spec simpler without loosing any features. |
There was a problem hiding this comment.
I think this description of Anoncrypt is not quite accurate. It allowed a message to be encrypted to the recipient in a way that absolutely did involve the recipient keys; what made it interesting is that the sender keys were ephemeral and newly generated for each message (and therefore unrecognizable to the recipient as belonging to anybody in particular).
There was a problem hiding this comment.
unfortunate typo: that should read ' involving the sender keys'. I have a reworded fix.
|
|
||
| Each message contains both the sender key (used in the encryption layer), and the sender's DID. The exchange of DIDs that occurs via the DID Exchange Protocol used in V1 occurs in each message that is transferred. Rotating DIDs is accomplished via the `prior_did` header. These features make the DID Exchange Protocol redundant. | ||
|
|
||
| One side effect of the DID Exchange Protocol in V1 was that you confirmed the validity of the DID with a round trip to the other party. Many protocols will provide this assurance via the flow of the protocol prior to the point where round-trip testing is required. When this round-trip is desired prior to the beginning of a protocol, a round trip with another protocol (such as Trust Ping or Feature Discovery) can provide the same assurance. |
There was a problem hiding this comment.
I fully agree with this paragraph. It is totally accurate. However, I remain uncomfortable that we're not adequately pointing out the significance of this semantic difference. Under V1, all protocols assumed that a secure pipe already existed and the DID of the first mover in the protocol would be pairwise and stable throughout the protocol run. Under V2, the DID of the initial mover/sender has to change at step 2 of the protocol to achieve the same guarantee, and all protocol impls need to tolerate DID rotation in the middle. If DID rotation is not used, and if the first message is OOB, then external observers can learn the DID and endpoint used by one of the parties. For some ephemeral use cases, this may not be a problem -- but as a general pattern, we have introduced a lurking antipattern that we should be warning against with documentation somewhere.
There was a problem hiding this comment.
I've cleaned up the language a bit. I think we need a guide section about DID Rotation, and why it must be used under normal conditions to prevent leaking the externally passed DID as you point out.
Signed-off-by: Sam Curren <[email protected]>
Signed-off-by: Sam Curren <[email protected]>
|
|
||
| Ephemeral mode in V1 was a method of passing messages without first performing an exchange of DIDs. Given that we no longer have a need to perform an exchange of DIDs prior to passing messages of another protocol, we no longer need to designate a mode for ephemeral interactions. | ||
|
|
||
| #### Use Peer DIDs (or other suitable DID method) in place of AnonCrypt |
There was a problem hiding this comment.
We still cannot use did:peer as I said in #33 (comment).
The from and from_prior fields would need to be tweaked such that DID URLs be used instead of just DIDs.
And even then, I'm not so sure of the implications of such a tweak...
There was a problem hiding this comment.
Well... I think the initial-state idea was completely scrapped from did-core... so now we depend on did:peer to provide the initial state in a DID.
There was a problem hiding this comment.
See relevant discussions for did:peer in:
There was a problem hiding this comment.
given wg call discussion on 2020/09/14, the DIDComm JWM profile needs to be adjusted to accommodate whatever method the DID spec/community chooses to pass off/pre ledger recorded information.
There was a problem hiding this comment.
As we talked about on the WG call, when we change to a DID URL we'll want to specify that during the "from" validation process the DID must be resolved to a full did document rather than de-referenced to only the key included in that DID URL. I agree that we're going to need to carry the parameters through though and changing from DID to DID-URL would allow this to occur.
|
|
||
| #### Message Level Decorators now represented as Headers | ||
|
|
||
| The adjusted structure of DIDComm messages now represents message level decorators as message headers. An example includes `thread_id`. |
There was a problem hiding this comment.
parent thread id will also need to be defined.
There was a problem hiding this comment.
given wg call discussion on 2020/09/14, we will update the JWM DIDComm Profile to pull forward thread_id as well as adding parent threads.
Signed-off-by: Sam Curren <[email protected]>
Signed-off-by: Sam Curren [email protected]