Terminology needs to be aligned and KERI only question (related)

[darrellodonnell]

Let me start off with stating that I really like the did:webs idea and I am impressed with the amount of work that has gone into it so far.

The specification is currently fairly non-normative. Right now there are far too many references to draft specs and terms that don't close the loop on definitions. I am pushing a PR that starts to close off some of the approach but I wanted to raise the issue here for broader discussion.

The pattern I see is that we have two intertwined issues:

• definitions are not complete - many are non-normative and others are missing.
• the only did:webs option appears to be KERI.

I could have raised this as two issues but I believe the problem is how these two tie together.

DEFINITIONS

My PR (#113) tries to unravel a gordian knot of terms that aren’t coming to completion. Part of that is helped by adding the ToIP Glossary of terms, which is intended to be normative. I think this should help. We have taken an action items to convene the TSWG chairs with the CTWG crew to see how we can reach rapid alignment.

KERI ONLY

While I get that KERI has a solution for did:webs I believe we should leave the door open for other solutions.

If we can support others, then examples need to be characterized that way. There is work required to get to that point:

• we need to separate the concepts (e.g. self-certifying identifier as concept) and concrete implementations (e.g. AID as concrete).
• we need to see if there are any other examples that could be brought in.

If there is only one way to do did:webs and that is KERI, then, at a minimum, we need to make KERI easier to approach. We should make the approach to KERI as simple as possible and explain only the parts/components of KERI that are required. This may mean a visit with the various KERI-suite spec writers is needed.

As an example, the KEL is clearly required, but a “KERI Event Stream” can have any number of things in it. What is mandatory for did:webs support?

Further, can we rename KERI Event Stream to something more general (e.g. Key Event Stream)? This supports the same concept as above - concept/concrete - though the dual use of K- to start the acronym could get confusing fast.

[2byrds]

Related to #101

[2byrds]

Also mentioned on slack by @swcurran here https://trustoverip.slack.com/archives/C05JPQBN571/p1704325268194999

[2byrds]

From our meeting today:
ISO bar is high. 'See KERI spec' is appropriate at times. For instance 'KERI witness' is necessary or not? They are useful for the story but non-normative?
Analogy of HTTP 1.0 to 1.1 and our spec 1.0 and 1.1 milestones where we march towards ISO level rigor in the spec. Our 1.0 is a good starting point and provides momentum. 1.1 and beyond continues to mature towards ISO rigor.

[2byrds]

The Task Force would like your review of our latest changes @darrellodonnell to see if we are on the right track.

[darrellodonnell]

I can't really add a lot of value right now. I see deep references to KERI that are non-normative and if the group is ok with that for the v1.0 then that's fine.

Is the intent to publish the specification as an "Implementor Draft" or as a formal/published ToIP specification. I'd advise the former (i.e. Implementor Draft).

I think that decision (Implementor Draft vs. formal specification) is the more important thing right now. This is along the lines of IETF and it's "We believe in rough consensus and running code" ethos. If you have the consensus and want to focus on running code for now, then great. Get the implementor draft out, get code running, and revise - then go to formal specification.

Note that the IETF approach is very different from an ISO approach.

[2byrds]

@darrellodonnell there has been significant movement on our side and wanted to check-in with you to see if we can resolve this issue.

[darrellodonnell]

OK - how has it been resolved? i.e. what do I need to look at/read?

[2byrds]

@darrellodonnell With this PR we have pulled the informative information that is implementors Guide section at the very end of the spec https://github.com/trustoverip/tswg-did-method-webs-specification/pulls and of course have indicated everything that is informative in our previous PRs.
Also @henkvancann would like to weigh in on including ToIP level terminology with the spec.

[henkvancann]

I go along with Darrell saying we have to define our own did:webs terms here and put the wording less KERI-ish.
As a matter of fact, the security side of did:webs is highly connected with KERI. As long as we don't have another identifier system behind did:webs as to offer the same features.

Soon we will have three options in terminology design under the umbrella of ToIP:

1. roll your own: define new criteria in term definitions
2. xref an existing term definitions
3. xref and comment / add context to an existing definition

Unfortunately the last option (3) is not yet available (and option 2/3 need authentication, for you might end up referencing something you did not choose back when you ref-ed it) and we need to keep track of history. Git commit hashes could help us out.

For the time being we could make a list of terms we need to change/ make more generic to invite other SSI systems into did:webs: [[def : newterm ]] and in the description

[[def : Key Event Stream ]]
 ~ This is an example of a more generalized term to be less [[xref : KE, KERI]]-ish 
but we're still tlaking about the same concept [[xref: KE, KERI event stream]].

This way we could temporarily circumvent the "problem"?

[2byrds]

@henkvancann I am okay with more generic terms for future efforts. But to avoid the delay of the ideal case, for v1.0 we should remain KERI specific and so the KERI specific terms should remain.