Remove the "editors note September 2022" as it is not useful

[swcurran]

I was surprised to read the editor's note from Sept. 2022. I see it was merged without feedback (including from me -- I wasn't aware of it). I'd like to see it removed on the basis that it steers people to two options that are not useful replacements for did:peer.

• While the caveat for did:key is present, it is not a replacement for did:peer precisely because of the caveat. Without a service endpoint, did:key cannot be used as a replacement for did:peer
• AFAIK, there are no implementations of did:keri as defined in the link. At the last IIW (November 2022) there was discussion and a session on the design for a did:keri that itself is only as far a PoC.

I don't see a need to redirect did:peer efforts at this time. It is AFAIK in wide usage.

I'd be interested in the items missing from the specification for alignment with the DID Specification as referenced in the first paragraph of the editors note.

I'll submit a PR for removing the note.

[brianorwhatever]

I am also in favour of reviving did:peer and can help with aligning with the did spec. I would also like to make some changes to the method as I believe there is a number of features that aren't used by anyone and make peer dids appear trickier than they are. For example is there anyone using dynamic peer:dids (see #45)?

[swcurran]

I agree with removing dynamic peer:dids or at least a lot of the complexity around them. @brianorwhatever -- how about doing a PR -- or at least a summary of what you would remove.

[brianorwhatever]

I would like to discuss more before opening a PR as there are a lot of things I would like to remove. See updates on #45

[swcurran]

@dhh1128 is there a forum for talking about issues around this spec? I have some new issues to raise as well that came up on the Aries Working Group call today.

[SmithSamuelM]

What would make me happy is some contributions of effort to finish the implementation of did:keri which provides essentially equivalent functionality. The one issue that I think was a hang up was discovery, but the OOBI mechanisms are similar and the did:peer backing store is essentially equivalent to the KERI KEL database. The KERIpy libraries are now being used in production so maybe its worth a discussion to do a comparison of the the did:peer algorithms to their KERI equivalents. If someone is going to spend cycles writing code to refresh did:peer (i.e. make a new version) then maybe its worth seeing if did:keri would be net net more productive.

[swcurran]

To me, the only purpose of did:peer (but it's super important) is to enable secure DIDComm channels, and notably, peer-to-peer DIDComm channels (pairwise). It feels to me like replacing did:peer with KERI is overkill. Even the complex parts of the did:peer spec seem like overkill -- the delta messages and change fragments and so on. I think of KERI as a heavy weight method for enterprise use around the issuing of credentials. I don't see them as lightweight DIDs created by a wallet for use in a connection to secure a DIDComm channel. Am I to have 800+ KERI identifiers in my mobile agent, one for each service I have a connection with?

The helps explain the misunderstanding of our last conversation, @SmithSamuelM, about where KERI identifiers as a DIDs are to be used.

[SmithSamuelM]

KERI direct mode is essentially designed to support the equivalent of secure DIDComm Channels in the same way that did:peer does. Direct mode means no witnesses, nothing but the identifier when its ephemeral and a KEL if its not (so the same as did:key for did:keri ephemeral) and the KEL provides the current key state for non-ephemeral (rotatable or transferable) identifiers that same way the did-doc in did:peer.

That’s why I suggested a comparison so the equivalencies would be more clear. Its easy to mischaracterize KERI because it can do a lot more but one can use it in a very stripped down mode.

One doesn’t need multiple algorithms with KERI because simply leaving the witnesses list empty makes it did:peer like and using ephemeral (non-transferable identifiers) which can’t have witnesses and don’t have KELs gives. that functionality. A KERI validator simply knows what to do.

I believe this is why Daniel @dhh1128 decided that did:peer 3.0 should be KERI.

Everthing a KERI validater needs is provided by the identifier alone if the identifier is nontransferable (ephemeral) and if the identifer is transferable then by the KEL. Other features are optional but are specified by the events in its KEL when it has one. So a did: doc feels very heavy weight for KERI. But I think that where we ended up in our discussion of thinking of KERI as more a did:peer like method from the standpoint of discovery and less like a did:sov method (as would be a KERI tunnel) makes it easier to implement did:keri in a familiar way.

From my point of view the complexity of did:peer with its various algorithms is overkill for its most popular use case whereas KERI functionality natural scales based on the inclusion of information in the KEL because its just validating an identifier and when applicable a data structure. Multi-sig and delegation add complexity but given a KERI validaton library you never see that complexity if you only use ever direct mode or ephemeral identifiers.

there is some work to hook up KERI to didcom but not more than revising did:peer

[SmithSamuelM]

Supporting the GLEIF use case which takes heavy advantage of multi-sig, delegation, witnesses, and a web-of-trust like architecture has kept the KERIpy team busy. And interoperability with didcom and did resolvers was not a necessity. But now that we are in production we want to enhance interoperability with the broader did ecosystem so open to help build interoperability bridges to KERI. And it sounds like many of those need only the simpler features of KERI which simplifies the bridge.

[dhh1128]

To Stephen's question about whether a forum exists to discuss did:peer's future, I suggest that we create one. Drummond was telling me he wants ToIP to transition from writing requirements for what it calls "layer 2" to formally specifying that layer, and I told him I was excited about that effort. Among other things, it would resolve the did:peer and KERI question. However, I said I wanted it to be not just a thin waist, technically, but also a tightly aligned political phenomenon as well. This means I want an answer that satisfies at least 4 important constituencies: @talltree's ToIP architects, the DIDComm efforts DIF led by @TelegramSam, the KERI community led by @SmithSamuelM , and the Hyperledger Aries world led by @swcurran . All of us are seeing essentially the same set of needs. I believe we are way more aligned that we realize, but are not fully aware of the beautiful synergy that is just waiting to be unlocked if we can frame the problem and the solution exactly right, and exactly the same way, in all those communities. A coalition of these groups would unleash SERIOUS adoption horsepower... I don't think users of did:peer need to adopt the heaviness of full-blown KERI support to get what they want. I think DIDComm can be simplified by letting KERI solve an authenticity problem and narrowing its focus a little, that this will not do much violence to ACAPY or other Aries tech, and that ToIP architects will love the result. We just need a forum to listen to one another and to teach one another for a while.

Given that it's almost the end-of-year holiday doldrums, I would like to propose that in January, we begin an alignment initiative among these 4 groups. We could use a regularly scheduled meeting of each of the groups in round-robin fashion (e.g., come to an Aries meeting, then go to a DIF DIDComm WG, then go to a WebOfTrust call, then go to a ToIP meeting).[1] I will volunteer to present a coherent vision that is one possible way of weaving all these threads together, if I can get the audiences to come with an open mind.

(BTW, Stephen, none of this undermines or undervalues the KERI bridge-building you are already doing. I know and love those efforts. I'm just thinking that this is one of those strange moments when, if we broaden scope a little more, a bunch of other pieces fall into place, and we have the counter-intuitive effect that things get easier and more beautiful instead of harder and more complex.)

---

[1] DIF and ToIP have compatible IP protection schemes, while WebOfTrust and Aries are lighter on that topic. But I don't think what we need to discuss is particularly dangerous from an IP perspective.

[andorsk]

I love the idea @dhh1128 proposed of trying to align the work across DIDComm, ToIP's TechArch, KERI, and peer.

Just want to second that I agree there's a ton of room for synergy and would love to get more involved if this becomes a joint effort.

I've had multiple discussions with other members of ToIP about the lack of alignment of frameworks in the SSI ecosystem and how that provides huge issues for adoption. This seems like a good example of an area where consolidation of efforts would provide enormous benefits for the community.

[talltree]

I am highly supportive of the cross-community effort described by @dhh1128. I believe it is exactly what will be required to establish the ToIP Trust Spanning Protocol as defined by the requirements in the first public review draft of the ToIP Technology Architecture Specification V1.0 spec. I am eager to get this effort started ASAP after the holidays.

Should we start a new issue dedicated to that topic?

[SmithSamuelM]

+1Sent from my iPadOn Dec 15, 2022, at 08:02, Drummond Reed @.***> wrote: I am highly supportive of the cross-community effort described by @dhh1128. I believe it is exactly what will be required to establish the ToIP Trust Spanning Protocol as defined by the requirements in the first public review draft of the ToIP Technology Architecture Specification V1.0 spec. I am eager to get this effort started ASAP after the holidays. Should we start a new issue dedicated to that topic?

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>