# DIDComm 0-RTT Proposal

The DID Exchange Protocol has one significant disadvantage: It requires the Exchange to be complete prior to a meaningful 'content' message to be sent. DIDComm is message based and asyncronous, but each party must come 'online' at least once during this exchange.

It is desirable to be able to send a message upon discovery of a DID without requiring a prior exchange. This is both more efficient in the common 'both online' case, and allows for efficient messaging when one or both parties are offline.

This proposal is intended to work with all types of DIDs: Ledger recorded, Peer, and DID methods using [initial-values](https://github.com/decentralized-identity/sidetree/blob/master/docs/protocol.md#unpublished-did-resolution) or similar parameters.

## Proposed Changes

There are two elements to the proposed change from DID Exchange to 0-RTT. First, the use of JWMs as the message delivery (envelope) protocol. Second, the use of the "Sender" in the JWM protocol as the mechanism for delivering pairwise DIDs for the connection. Since message envelopes are used for exchanging DIDs, we don't need content protocol messages for that.

The [Sender in the JWM Envelope](https://hackmd.io/DURqeSg2SOy-Ol2ZjfXKUg) of a DIDComm message is a DID Key Reference. A recipient is able to decrypt the sender, and resolve the key used to continue decrypting the message. If the sender DID key reference is either a public DID on a ledger or a DID with an initial value parameter, the recipient shall use it as the pairwise DID for the sender.

Take the scenario where the _invitee_ gets the _inviter_ DID from a discovered source, such as a published public DID. If the inviter DID is not intended to be rotated, and the first message from the invitee contains its DID for the connection in the Sender of the JWM envelope, the exchange of DIDs is done, and each party is aware of the other's DID. Note that the invitee can use either an existing DID or create a new DID for the connection.

### Implicit Invitations

Just as in DID Exchange, implicit invitations exist in the form of a DID. When a DID is discovered via any method (Issuer, Well Known DID, etc.) it can be used to begin an interaction. This is particulary useful for institutions that desire a well-known DID.

### Explicit Invitations

Explicit invitations can also be used to apply context or begin interaction in a new exchange

Context can be maintained between invitation and interaction in several ways, including the use of a uniqe DID and a message passed in an OutOfBand Invitation or similar.

Invitations would present a DID, a label, and Message ID Thread information to provide both context and a smoother user experience.

OOB Requests may be much more useful than invitations, as they contain an actionable message instead of an invitation to send one.

Reuse of a connection with an invitation is also automatic, simply send a `hello` message (see below) or respond to the message contained in the OOB request.

### DID Rotation

When responding to a message following an invitation, the _inviter_ must rotate away from the DID used in the invitation to maintain privacy. This rotation includes the new DID, along with a reference to the previous DID and authorization to rotate. This rotation is sent in the next message to the _invitee_. To avoid the need to precoordinate this, it is desirable to communicate this information at the JWE level. This might look like the following:

did:example:newdid?...&replacingdid=did:example:olddid&replaceauth=<signature from old did of new did>

## Discussion

### Default to non-rotation of Invitation DID/Info
While non-rotation of invitation information is technically allowed in both DID Exchange and 0-RTT, the differences in handling degrade the default behavior.
DID Exchange requires a `response` message even if you decide not to rotate the information. 0-RTT requires the sender to rotate the DID (described above) to maintain privacy.
It is easier to forget to do something than ignore it on purpose.
It is possible for the _invitee_ to get angry about a non-rotation. Perhaps this is a mechanism for compliance?

### Length of DID in Sender Field
With `initial-values`, this could become quite long. What expectations or limits should be applied to the DID in the sender field? How does this relate to query param work in the DID Core spec?

### Confirmation of connection
DIDComm has an explicit `complete` message to indicate the exchange is complete. 0RTT implies that _any_ message from the other party signals it complete. This mimics the implicit ack we had before on the Aries `connections` protocol, which we didn't like.

On the other hand, there isn't a set of protocol messages here. Perhaps a correction of our mental model will make the need for an explicit confirmation not necessary.

### Providing initial information
The ability to send a secure DIDComm message to another party does not establish trust. By agreeing upon a nonce strategy, proofs with a carefully created nonce can be sent (without exchange) to establish trust. These proofs can be sent as additional messages (pipeline style), or as attachments to the main message. This method can be used to leverage VCs for trust, and also may allow for MITM detection.

Other protocols can also provide value here, such as the `discover-features/disclose` protocol message to inform the other agent which protocols you support.

### Decryption must wait for DID resolution for new sender

This is true, but actually has some desirable properties. If the message can be decrypted with an inline key, a secondary verification step must take place to verify that the used encryption key is associated with the sender DID present inside the encrypted portion of the message as a JWM attribute.

If the DID Key reference is used as the sender and the key resolved, then the verifiation step is automatic.

If we agree that the key used for sender and the internal DID must match prior to processing the message, the order of (decryption, resolution) seems unimportant.

### Do we need a 'Hello' message?

The 0-RTT strategy allows the first message to be meaningful. Do we need a message to use in the absence of any other relevant message? The other option would be to designate something like a trust ping to allow both sides to confirm a successful connection.

Use of such a message allows the inviter to respond to a new `connection`. Use of an inline message (such as OOB-Request) allows the invitee to 'initiate' the flow (though it really is responding to the OOB-Request message).

### Maintaining Pairwise DIDs

While we have not applied much effort in Aries to maintaining DIDs within a connection (additions, key rotations, etc.), the did:peer specification proposes a process. Given the current DID Exchange content-level protocol, the expectation has been that other protocols would be defined to enable one agent to notify another of updates to it's did:peer DIDDoc. Will that interaction also be transmitted via the envelope in the same way as the initial values and initial rotation?

## Issues that are out of scope
- MITM Prevention

## Related Links

- [JWM DIDComm Full Example](https://hackmd.io/DURqeSg2SOy-Ol2ZjfXKUg)
- [DIDComm Messaging REPO Issue 38](https://github.com/decentralized-identity/didcomm-messaging/issues/38)