Adds Alg 4

[TelegramSam]

Adds @dbluhm's Alg 4 into the spec.

[swcurran]

Very minor editorial notes. Looks great!

[Patrik-Stas]

Hi, we will start implementation in aries-vcx of this perhaps through out the next week or beginning of October.

It would be great if the PR can stay open for a while, so we can provide feedback from our experience implementing this.

[dbluhm]

https://github.com/dbluhm/did-peer-4/issues/1#issue-1912277683

My only point against this did:peer:4 is why complicate everything else with two identities. Other than that I love the idea.

IMO is complicated enough controlling one identity and here we are proposing to identities that come always in pairs:

did:peer:4{{hash}}:{{encoded document}} did:peer:4{{hash}}

Was it considered to use DID query? Note the the query part of a DID is not part of the identity! On the contrary of DID path. (The DID fragment is also not part of the identity but can't be used on the DID Comm message field id.)

did:peer:4{{hash}}?doc={{encoded document}} <=> did:peer:4{{hash}} Those two are equivalent in terms of identity. According to the DID core specs they are one identity.

[dbluhm]

@FabioPinheiro The two forms, long and short, do not represent two separate identities. The whole idea is that they represent exactly the same set of keys and endpoints. The goal of the short vs long form is to enable more compact kids in DIDComm v2. That being said, it is technically perfectly acceptable to always use the long form of the DID.

A DID query was briefly considered; however, there is precedent in the form of did:ion for having a short form and long form style DID. Then, the documents resolved from short and long form are declared to be "aliases" for each other through the use of the alsoKnownAs field. This bidirectional AKA is exactly what is referred to in the note for that field found here: https://www.w3.org/TR/did-core/#dfn-alsoknownas.

Copying note for emphasis:

Applications might choose to consider two identifiers related by alsoKnownAs to be equivalent if the alsoKnownAs relationship is reciprocated in the reverse direction. It is best practice not to consider them equivalent in the absence of this inverse relationship. In other words, the presence of an alsoKnownAs assertion does not prove that this assertion is true. Therefore, it is strongly advised that a requesting party obtain independent verification of an alsoKnownAs assertion.

Given that the DID subject might use different identifiers for different purposes, an expectation of strong equivalence between the two identifiers, or merging the information of the two corresponding DID documents, is not necessarily appropriate, even with a reciprocal relationship.

In my opinion, this is the closest match for our goals and the cleanest way to express the relationship between the short and long form in a way that is supported by the DID Core spec.

[dbluhm]

Agreed with @FabioPinheiro, we should correct these examples to make sure we're promoting correctly constructed didcomm v2 services and not causing any confusion.

[swcurran]

Definitely want the examples right!!! Thanks @FabioPinheiro !

[dbluhm]

https://github.com/TelegramSam/peer-did-method-spec-1/pull/1

[TelegramSam]

TelegramSam#1

I did not know you could do that. 👍

[TelegramSam]

@FabioPinheiro examples corrected.

[dbluhm]

I built a tool for quickly parsing/resolving and generating did:peer:4 DIDs:

https://dbluhm.github.io/did-peer-4-ts/

And another link with a DID queued up.

[TelegramSam]

Now merging, given the approvals, implementations, and time.