{
- "change": <base64 encoding of a change fragment>,
+ "change": <base64url encoding of a change fragment>,
"by": [ {"key": <id of key>, "sig": <signature value>} ... ],
"when": <ISO8601/RFC3339 UTC timestamp with at least second precision>
}
Here, a change fragment is a sparse version of a DID doc that shows just the section being
- updated. The by property contains one or more key+signature pairs over the raw (non-base64-encoded)
+ updated. The by property contains one or more key+signature pairs over the raw (non-base64url-encoded)
JSON text of the change fragment, and when contains a value supplied by the system clock. This
value is like timestamps on an email header—not guaranteed to be highly accurate, but useful for rough
analysis.
Deltas are uniquely identified by the SHA256 hash of the raw (non-base64-encoded) bytes of their change fragment, +
Deltas are uniquely identified by the SHA256 hash of the raw (non-base64url-encoded) bytes of their change fragment, and so are the change fragments themselves. Two change fragments with the same semantic meaning but different indents or different attribute orders are considered different changes. This is because peer DIDs entirely ignore the thorny problem of JSON canonicalization. The raw bytes of change fragments are normative and MUST @@ -202,7 +202,7 @@
authorization.profiles associates the new key with privileges. This must be done at creation
time. It is discussed under authorization.) The delta that
- encapsulates this update would take the above JSON text, base64-encode it, and assign the result to the
+ encapsulates this update would take the above JSON text, base64url-encode it, and assign the result to the
delta's change property. It would need to be authorized by a key with the key_admin
privilege, evidenced in the delta's by field. The resulting delta might look like this:
@@ -231,7 +231,7 @@ This fragment would be base64-encoded and signed in a corresponding delta, in much the same way that +
This fragment would be base64url-encoded and signed in a corresponding delta, in much the same way that the fragment was handled in the example about adding a key.
diff --git a/protocols.html b/protocols.html index 13195b6..e593a6b 100644 --- a/protocols.html +++ b/protocols.html @@ -58,8 +58,9 @@One of the parties (the inviter) sends an invitation to connect. The
invitation is NOT encrypted, and it does NOT require the recipient (the invitee) to
have special software that understands this protocol. Instead, it is a specially formatted URI
that can be a
@@ -79,22 +81,27 @@ DIDComm Approach
can be recognized by a registered handler, short-circuiting the URI fetch and the onboarding/
learning process. This invitation URI may be transmitted by email, SMS, QR code, or any other
convenient method. If it is important to the inviter that it be secured, the inviter can share
- the invitation on a secure channel. Important to note that if the messaging is to be done
- anonymously without sharing of personal identifiable information (PII) between both parties the
- invitation should not be transmitted to personal email, sms, etc. A one time identifier shall be
- used to send initial invitation.
+ the invitation on a secure channel.
+
If this relationship is intended to preserve anonymity, it should not be sent from + or to personal email, sms, etc. Instead, a one time identifier should be for whichever side(s) + wish be anonymous. +
These three steps have been carefully defined to achieve a number of important goals:
@@ -119,14 +126,16 @@Additional security against man-in-the-middle attacks may be achieved by signing an invitation, if it is - public. If the public invitation includes an anywise DID, then the invitee should verify that the - signature on the invitation matches with an active verification key for the associated anywise DID. If the - public invitation includes a verification key, then the invitee can verify that the signature on the - invitation matches with the verification key. Once the DIDs are exchanged, the invitee can - ask the inviter for proof-of-control of that initial verification key. In any case, further action is - advisable to build deeper trust about the identity of the other side. This likely includes mutual exchange - of verifiable credentials. +
+ For public invitations, additional security against man-in-the-middle attacks may be achieved by signing + the invitation message. If the public invitation includes an anywise DID, the invitee should verify + that the signature on the invitation matches with an active (not revoked!) verification key for the + DID. If the public invitation includes a verification key, then the invitee should verify that the + signature on the invitation matches that key, and once the DIDs are exchanged, the invitee should ask the + inviter to prove they still control that verification key. Regardless, having a trustworthy channel of + communication is not the same as knowing that the party you're connected with is trustworthy. Further + trustbuilding should usually follow the initial connection. This + likely includes mutual exchange of verifiable credentials.
The subject of a peer DID can update their associated DID document with anyone who knows the DID—one or more - agents of the peer(s), or agents of the owner. This operation is more important in the peer DID method than + agents of the peer(s), or agents of the subject. This operation is more important in the peer DID method than in most other methods, because a loose collection of decentralized peers may include many different views of current state, caused by inconsistent and incomplete connectivity within the peer group.
@@ -225,8 +234,7 @@~thread decorator identifies the previous message's @id as its
thid.
- If the recipient does not recognize the base_hash, it selects a hash from a point in time earlier than +
If the recipient does not recognize base_hash, it selects a hash from a point in time earlier than
base_hash_time and sends back a new sync_state message with that earlier base.
Because of the nature of our CRDT rules, truly