Remove references to "non-transferrable" KERI identifiers about tswg-did-method-webs-specification

[dhh1128]

Hmm.

Transferability and publication are two different issues. An AID can be published so it's resolvable by the public, but not support key rotation.

You need key rotation if a DID is going to be used to take many actions over a long lifespan. I think this means it would be crazy for an institution that wants to issue credentials to publish an identifier that doesn't support rotation. However, I'm not convinced that the same logic applies to individuals who receive credentials or who simply want to communicate with the public. It would depend on the use case. Individuals can just unpublish and throw away DIDs that they don't want to use, whereas that's impractical for institutional issuers.

If I give a presentation at a conference, maybe I publish a did:webs so the audience can establish DIDComm connections with me (anybody who does, I create a unique new DID dedicated to the connection). I leave the DID active until the conference ends. Then I take it off the web. I want the public characteristic, but I'm not sure I want the key rotation characteristic.

[dhh1128]

if the “non-transferrable” KERI identifier has an associated event that we can enumerate

It does.

and an associated business value in the DID world

It does; it brings KERI folks into the DID world by allowing them to identify anything in their world with a did:webs, rather than keeping them separate by saying that only some of their constructs are worthy of did:webs expression.

should not be referenced “just because”

I already proposed that we just remove all references to the concept, which is maximally simple and also maximally inclusive. It is not possible to preclude non-transferrable AIDs unless we explain what the concept is, and ask people to implement special rules to preclude that subset of KERI features, so the spec gets uglier if we go that way.

[peacekeeper]

Our goal for did:webs is to be a web-based DID method that uses KERI, not a KERI-based DID method.

I'm not sure if there is agreement on this. What you are describing sounds more like the did:webplus approach to me, i.e. defining some kind of "stripped-down" version of KERI in order to secure did:web.

The downside of this approach is that it would be much harder to switch from did:webs -> did:keri or from did:webs -> native KERI, because they wouldn't be using the same "variations" of KERI.

[dhh1128]

Is this summary of the point actually true? I'm genuinely curious. I had not considered it to be even slightly true, but perhaps I need to learn something. What is it about did:webs that makes it inherently interested only in transferrable identifiers?

[swcurran]

I think the “s” implies security, which includes the ability to rotate keys. And we are not trying to replace self-certifying peer dids.

[dhh1128]

Rotation only provides security if a DID is expected to be long-lived. Are you assuming that DIDs published with this method are always long-lived? (I'm not necessarily opposed, just trying to clarify your rationale.)

[swcurran]

Yes. Here is the rationale.

If I go to the trouble of creating a did:webs in a public place, it is because I expect that the identifier will be put into a document of some kind (e.g. a VC) that will be arbitrarily shared, such that when someone receives the document, they can resolve the DID. If I'm only sharing the DID directly with another party, then I would not need to go to the trouble of putting it in a public place.

Of course I can use the DID in a private way if I want, but that’s definitely not the intention.

[swcurran]

But is that relevant to this DID method? To create a did:webs, you execute some events using a KERI DID event processor in some way, and then you publish the outputs. If you don’t use events thats allow rotation, that’s up to you. The did:webs method doesn’t care how you created your DID, or what you do with it after you create. Same with any DID method. There is no need to get into that level of complexity in the DID method spec.

[dhh1128]

My read of the introduction to this issue was that we were asserting the irrelevance of some KERI features. To paraphrase: "this DID method doesn't need those features, so let's not mention them" -- or "let's insert a sentence explicitly announcing their irrelevance." I was dubious about the irrelevance, because I think this DID method has a very broad range of use cases that go well beyond support for credential issuance and whois. However, I don't mind the recommendation that we simply omit any mention -- as long as what remains doesn't preclude the KERI features we unmention.

[swcurran]

Here’s how I view it:

• Entities resolving DIDs want the DIDDocs so that they can do “DID things"
• Entities resolving DIDs want to know that they are “verified” — a true/false.
• Entities creating DIDs want their DIDDoc to be verifiable.
• Entities creating DIDs will use a set of KERI features to achieve that — firing events at the KERI Event Processor (Slack message quoted below about those, to capture it here).

I think that is what the DID Method should cover. How KERI is used to enable those things. And there should be a reference to say “And KERI can do a lot more…”, such that:

• An interested entity resolving the DID can use the data in the KEL to do more (find Witnesses, Watchers, Witches, Warlocks, etc.)
• An interested entity creating DIDs can use the many more features of KERI do do more things

From my Slack message:

The controller needs to do a series of operations that impact the DIDDoc, and allows the publishing of signed documents in the DID folder. Those operations are (non-exhaustive):

• initialize
• add a key
• setup multisig (TBD exactly what that means)
• rotate a key
• add a service endpoint
• sign a document
• sign a verifiable presentation
• add an AlsoKnownAs (aka redirect to a new did:webs location)

The party using the DID:

• Read a DIDDoc with verification
• Read a Document associated with the DID with verification
  • Including verifying a document signed with a subsequently rotated key
• Retrieve and verify a verifiable presentation associated with the DID (subject is the DID)
  • Including verifying a VP where the subject ID is an AlsoKnownAs (controller redirect)
    • Including verifying a VP signed with a subsequently rotated key

[dhh1128]

You are describing what the did method will do entirely from the perspective of people who want to (continue to) live in the intersection of DID-land and web-land, and who want to use KERI as an incidental tool to derive benefits in that ecosystem. That's a perfectly valid perspective, but it's very self-referential. In that view, did:webs is a method to use between parties who share all of the same worldview assumptions from those two ecosystems -- and no other ecosystem constituencies matter:

However, I think there's another valid perspective, and I want us to consider it. What about people who live in KERI-land, and want to use this did method as a bridge to folks that don't speak their language? Is it reasonable for them to look to this DID method as a way to expose a subset of their KERI constructions, making them accessible to and usable with parties who don't know their world? Does a third constituency deserve any place in the venn diagram?

GLEIF and Provenant both fall into this third category. We don't need a DID method because we lack a way to create secure and resolvable identifiers. We need it because we need a way to express our constructs in a way that the DID and web communities can understand. And if our dreams come true, tens of thousands of orgs that have vLEIs will have a similar desire over the next year or so.

Please don't think that I'm arguing that did:webs has to be a KERI advertisement, or that it must support all KERI features. Of course it doesn't have to do that. However, I'd vote to eliminate a KERI feature from the DID method not based on whether it narrowly meets your criteria for satisfying the did+web folks, but based on whether it is hard to model or implement in DID-land. Non-transferrable AIDs don't fall into that category -- they are just a nulling-out of some data in the KEL -- so deliberately excluding them from the scope of the spec limits the kinds of DIDs that a native KERI party can send over the bridge, without saving any implementation cost. How is that helpful?

[dhh1128]

I see two valid counterarguments to what I just said, and I want to acknowledge them.

1. That's why we have the did:keri method. If you want to expose KERI features across the board, use that.
2. There is no gravitas around KERI, so it doesn't deserve a place in the venn diagram of considerations.

I think there is some truth in both of these arguments, so if you push hard on them, perhaps I'll be convinced. However, I'd like to explain why neither of them convinces me at the moment.

Re. 1: I don't actually see did:keri building bridges, because the only people that will use it exist outside the intersection of the first two circles in my venn diagram. It might have a future in the long run, but I think its immediate adoption path is constrained. It lacks the web virtues of did:webs that make it accessible to people with a different tech background. Further, if your prediction is true, Stephen, that did:webs has the potential of acquiring huge gravitas in DID-land, the need for did:keri in DID-land goes down. Hence, I think being pure about did:webs servicing only use cases and features as imagined by the overlap of the first two circles in the venn diagram effectively keeps KERI out of DID discussions.

Re. 2: The "no gravitas" argument is always true about anything new. Whether it will remain true is unknown. If we don't want to create self-fulfilling prophecies, I don't think it's a valid way to decide the question.

[swcurran]

Your counterarguments capture most of what I would say in response to your previous comment. I do think that KERI needs to be talked about in the spec as it used in the spec (as I said above), the events described and outcomes. I think there should paths to let people know "you can do a lot more with KERI", but I think that should point elsewhere, not be included.

After looking at did:plc, I think that the really important features from KERI (chain of linked events, pre-rotation) can be done a lot easier than KERI. On the other hand, having multisig thought out and useful (as I understand it is with KERI), is very valuable. I just added the signed files section, and the idea of being able to have published files from a multi-party DID is powerful. I suspect that there are other features of KERI that can be exposed in the DID Method. But that said, I'm very much a believer that this is a DID Method first, for use in DID land.

[peacekeeper]

I'm with @dhh1128 on this. I cannot understand why the KERI-based did:webs method might possibly want to "artificially" constrain itself to allowing only a subset of KERI. I think this would make everything much more complicated. In the spec, we would have to somehow enumerate all the things that this DID method would "subtract" from KERI. Who would decide which KERI features are "allowed" in this DID methods, and which ones are not? Users would likely wonder why some AIDs work in "native" KERI but don't work in KERI-based did:webs. There would also be lots of interoperability problems between did:webs and did:keri.

Propose to close this issue.

[swcurran]

I still disagree. Our goal for did:webs is to be a web-based DID method that uses KERI, not a KERI-based DID method. The features of KERI that we are using should be explicitly called out, through the list of events that can be processed. We have discussed that before — that the spec needs to outline the set of events that a Controller can perform, each of which both adds to the event log and produces a business value (alters the DIDDoc, signs a file for publication, etc.).

A separate “did:keri” can be defined that extends to all features of KERI, the did:webs spec can be altered/extended to add more features as is demanded by the ecosystem.

[swcurran]

An additional note — if the “non-transferrable” KERI identifier has an associated event that we can enumerate, and an associated business value in the DID world, great. I’m just saying that KERI features that can’t be described that way should not be referenced “just because”.

[2byrds]

I talked with some GLEIF and some RootsID folks and they all believe we should support non-transferable AIDs. From my POV I've been thinking about infrastructure things in the KERI ecosystem and they often have non-transferable AIDs, but many are web-based resources and I'd like those things to have did:webs for easier discovery and associated (verifiable) web content.... I'd want didcomm to be in-play for those resources, etc. They will probably have a did:webs and a did:keri but most importantly I agree that it will be MORE work to not support them, since they are the simpler AID (a KEL with a single inception event).

[2byrds]

I agree with both @dhh1128 and @peacekeeper points

[swcurran]

If a “non-transferrable” KERI identifier is one for which there is just an inception event, then I agree it is, by definition, supported. I also think there is no need to mention it in the specification. Any one can choose to execute as many or as few events as they need to meet their goal.

My only objection was that it be treated as something different from other KERI AIDs— which by naming it as something different we seem to be doing.

So I agree we can close this issue.

[pfeairheller]

Agreed to close in Task Force meeting on 9/22/2023