DID WG Telco — Minutes

Date: 2020-12-08

Attendees

Present: Ivan Herman, Justin Richer, Shigeya Suzuki, Amy Guy, Markus Sabadello, Wayne Chang, Manu Sporny, Brent Zundel, Drummond Reed, Adrian Gropper, Michael Jones, Dmitri Zagidulin, Ted Thibodeau Jr., Orie Steele, Dave Longley, Jonathan Holt, Joe Andrieu, Eugeniu Rusu, Kaliya Young, Juan Caballero, Daniel Buchner

Regrets: Daniel Burnett

Guests:

Chair: Brent Zundel

Scribe(s): Manu Sporny, Amy Guy

Brent Zundel: Agenda today — special topic call, issue 199, jump into issue processing P1 then P2 issues.
… Any additions to the agenda?

1. Introductions and Reintroductions

Brent Zundel: No new members, skipping introductions we all know each other

2. Special Topic Call

Brent Zundel: Goal of call today is to finish up security/privacy questionnaire — last session was very productive, please join if you feel that you can help us move forward and get that done.

3. Issue 199

See github issue #199.

Brent Zundel: Possibly last of the issues that need to be discussed — at this point there are a few changes on how we could move forward

Brent Zundel: https://github.com/w3c/did-core/issues/199#issuecomment-738333023

Brent Zundel: Let’s time box to 10 minutes to briefly discuss the issue — clarification of what DIDs might identify
… I feel awkward about talking about this — I raised it, but doing my best to not do it w/ my Chair and/or company hat on.
… This issue is about how to express information resources as part of information resource — there are four possible ways of doing this — define DID Document property to contain DID Subject, define new metadata category to return DID Subject, or define DID Resolution input metadata property to indicate that when DID is resolved, DID Subject should be returned rather than DID Document, or new DID Parameter.
… Jump on queue if you have suggestions/thoughts.

Manu Sporny: could you outline a concrete use case? I believe it is something like you have a schema that has a DID associated with it and you want to return the schema and not the DID document, but I might be misunderstanding?

Brent Zundel: Yes, we have an information resource that is a schema identified by DID — it is the DID Subject, resolution of DID would like DID Subject returned in addition to information returned in DID Document… important to see who controls the subject, and that is information representation in DID Document… initial attempt was content property, which then turned into representation, then type, which turned into a bad idea… how can we do this?

Adrian Gropper: I see this as a pure authorization problem. I know there’s been discussion about this over the weekend… see this entirely as an authorization issue.

Jonathan Holt: How do we do this w/ authorization? In IPID method, create submethod name, schema, same thing when you resolve DID Document, you can also resolve schema… ipid:schema: … that’s how we were going to handle it — how can we do this w/ authorization?

Markus Sabadello: I’d be opposed to allowing resolution of a DID — resolution not dereferencing, when you resolve a DID you can’t get anything other than a DID Document.

Amy Guy: +1 to markus

Markus Sabadello: I would be open to saying that you resolve the DID and you get a DID Document, and that has a property that contains the subject… when you dereference a DID, you could get something other than the DID Document… we shouldn’t change basic assumption, when you resolve a DID you get a DID Document.

Joe Andrieu: It’s important to be able to resolve w/o dereferencing — this property wouldn’t allow that when it’s used… that seems to be a layer violation… could have impact on herd privacy. We should allow resolution as a distinct step from dereferencing.

Brent Zundel: good feedback

Drummond Reed: I was going to ask why Adrian thought this was an authorization problem?

Brent Zundel: It sounds like, of the options we went through — Joe is uncomfortable w/ option #1… wondering now about option 3 - as part of resolution input metadata, the entity resolving DID — also give me Information Resource identified by it, option 4, did parameter that is a URL that could be dereferenced to retrieve DID subject.

Adrian Gropper: the explanation is — entirely consistent w/ resolution should be separate from dereferencing… DID Document is a public document in general… as far as spec is concerned, we should consider it to be public — therefore, distinction between dereferencing needs to be protected by authorization step.

Markus Sabadello: Small modification about option 3- input metadata property to request DID Document or DID Subject… if we could change that to “dereferencing input metadata” resolving never returns anything other than DID Document… parameters or metadata properties — dereference the did, metadata property, could return something other than DID Document… not mutually exclusive w/ option #4.

Ivan Herman: Listening to that, I don’t understand the use case.
… When you say it returns the schema… does the method have the schema somehow in it’s own database and it returns file containing schema, or does it return URL of schema which is somewhere on the Web, or does the method have to dereference to somewhere on Internet and returns that…

Brent Zundel: #1 — return the file.

Ivan Herman: Sounds like a narrow use case.

Brent Zundel: A large community cares about this use case.

Drummond Reed: Two quick points - as an editor, huge mistake to assume DID Document is public… we should make sure we cover that case, but there are thousands of use cases for DID Documents that are private — shared between peers… so to impose on the spec that all DID Documents would be public.

Orie Steele: Is it true that the desire to support schemas and did documents in the same system is to support certain ZKP credential formats such as Indy Credentials?

Drummond Reed: Interested in a parameter for requesting dereferencing — all for resolution, but if you want for efficiencies sake, compose URL that ask for dereferencing — that’s option #4.

Brent Zundel: We have a minute left and then we need to move on… Excellent feedback so far.

Manu Sporny: veres one has a use case where we store capabilities on ledger, in veres one the DID doc is a capability itself. We have explored other things being stored in DID docs that are kind of like the use case brent outlined
… one workable thing would be why don’t we create a narrow property called schema if you want to put a schema in a DID doc, adn we create other narrow properties
… we may be trying to overgeneralize this feature
… we need to be very specific about what we want
… keeping dereferencing separate from resolution is a good thing to do architecturally but it may confuse this because other parts of internet infrastructure may work that way so it may be a weird thing for people to understand
… trying to figure out the simplest way to address the issue, putting a specific property in a DID doc might be the first easiest way
… we can talk about the more complex things like resolution and deferenerncing giving back different things
… there’s a use case in veres one that’s sort of interested in figuring out the answer to this question but i’d like the group to pick the simplest thing that is nto going to create more cognitive overhead for developers

Drummond Reed I’m worried that we’re going to end up with a growing list of properties being added to DID Spec Registries for all the different types of content that might want to be included in a DID document

Dave Longley: if you had a URL like this: “did:method:1234#representation” and it resolves to the DID Document “did:method:1234” and when dereferenced, you get whatever it says about “did:method:1234#representation” you get a technical separation of resolution/dereferencing

Drummond Reed: Agree with Dave

Dave Longley: (not unlike dereferencing verification methods)

Amy Guy: that narrow property sounds like an extension / for the registries rather than a core property

Joe Andrieu: regarding Drummond’s comments — public vs. private — important thing isn’t “all did documents are public”… rather, “herd privacy requires they be indistinguishable”… properties unique to subject can cause problems w/ herd privacy.

Brent Zundel: +1 to the importance of herd privacy

Ivan Herman: I understand the use case and accept it — maybe this is what Joe was saying — there is a layering issue… the method, as far as DID is concerned, does resolution and returns DID Document… but there is DID URL, which is different thing… method stores something other than DID DOcument, so you want to give separate access to other information — those two things are very different… I’d use a different access mechanism… DID URL might be the different tool for this… “I don’t resolve now, I use other functionality”, these two things shouldn’t be mixed.

Jonathan Holt: +1 to ivan

Markus Sabadello: we already have scenarios where dereferencing a DID URL returns something other than DID Document, service selection, for example — not a new idea.

Brent Zundel: Ok, that helps, will move on to issue processing

4. Priority 1 Issues

Manu Sporny: https://github.com/w3c/did-core/issues?q=is%3Aissue+is%3Aopen+label%3Apre-cr-p1+sort%3Aupdated-asc

Brent Zundel: 118 — WCAG - we know that, we’ll make those changes before CR
… 292 is staying open to keep tracking going
… 119 - TAG review is waiting on completion of security/privacy questionnaire, will be hopefully done by this evening.

Brent Zundel: https://github.com/w3c/did-core/issues/361

Brent Zundel: 361 - define serializations for numbers, dates, other properties

Manu Sporny: there are PRs in flight to address this
… one last PR i need to do to the cbor section to bring it in line
… once they go in this issue will be addressed. Please review the PRs

Jonathan Holt: https://github.com/w3c/did-core/pull/476

Brent Zundel: https://github.com/w3c/did-core/issues/384

Brent Zundel: 384 - normative statements review
… List of all of normative statements — we need to review these.

Manu Sporny: what we really need for the list is 1) the editors to go in and check but it’s really going to be driven by people writing tests
… I expect this will float out there until the tests start getting written
… ideally we have good test coverage before we go into CR
… but there’s a ? over that right now
… if we’re not writing tests we’re not going to have good coverage
… the companies that have stepped forward to do the tests have not been writing tests

Orie Steele: please see https://github.com/w3c/did-test-suite/issues/17

Ivan Herman: s/?/question/

Daniel Buchner: I will write at least two more to help

Orie Steele: Yeah, I spent some time this weekend taking another stab at test infrastructure in another WGs test suite… got some major refactoring/structural changes and make it easier to write tests… would require changes… test suite, please review issue I raised.
… The teaser is — what if we could have a button that we could click that could test vendor conformance automatically — run the tests via website…

Brent Zundel: Chair call out for test suite — any orgs who have not committed, we’d love commitments there.

Orie Steele: please also review https://github.com/w3c/did-test-suite/pull/16

Michael Jones: You don’t have to use RFC 2119 language for a statement to be normative. For instance, saying that “The value of foo is a JSON object” is just as normative as “The value of foo MUST be a JSON object”. The list in the issue appears to only be a list of statements using 2119 language - not all the normative statements. Do people agree or disagree?

Manu Sporny: Mike, I disagree wrt. testability

Brent Zundel: Last open issue — 199, clarification on what DIDs might identify, we’ve already identified some next steps to move that one forward. Those are the P1 issues.

Jonathan Holt: Just to clarify the test suite — what are testing for completeness of specification.
… Constraints on DID Document, confused on how we’re writing these tests in a way that is abstracted wrt. abstract data model

Manu Sporny: mike, I think your right in a handwavey way, the only thing that we’re going to translate into test suite tests are MUST statements
… saying that you don’t need to use rfc2119 language to be normative, I think i’ts misleading
… the only thing we are going to be testing are the MUST statements in the specification
… anything else that seems normative will be asserted that it is not normative if you don’t have a MUST or a SHOULD or a MAY
… if we don’t do it that way it is very difficult to say what a normative statement is
… to be crystal clear, without rfc2119 language it is not a normative statement
… the example in IRC is not a normative statement. the value of foo MUST be a json object. We would reword the statement to have the MUST in there

Michael Jones: All language is normative unless marked non-normative. “The value of foo is a JSON object” is normative. Completely disagree

Orie Steele: Agree with everything Manu just said, trying to answer jonathan_holt directly — purpose of tests is to cover normative statements.

Michael Jones: Then why would we say that “The value of foo is a JSON object” if it has no meaning?
… “declarative” statements are testable

Justin Richer: +1 to manu’s point. There’s a subtle difference between “normative” and “declarative”

Orie Steele: We should kick things out from the list that are not normative - we want things to be testable… do different DID Methods conform to test suite? We would like test suite to solve for both, but let’s get things testable and make sure list is accurate and a thing we want to write tests around.

Ted Thibodeau Jr.: “if not worded with RFC2119 language, we didn’t intend it to be normative” is a meaningful statement. It would be great to get a list of normative statements that don’t use RFC2119 language, so they can be reworded, whether into 2119 or out of non-2119 normativity.

Dave Longley: +1 to TallTed

Orie Steele: As someone that signed up to write tests, list needs to be clear and definitive.

Manu Sporny: +1 to TallTed

Amy Guy: brent ^ sorry typed it

Ted Thibodeau Jr.: I don’t see a way to do that with technology, so volunteers would be welcome. (I cannot volunteer to do this.)

Amy Guy: is a “ statements should all be captured by a prior “MUST be according to following:
… I agree that if a statement should be normative but doesn’t use rfc2119 language it should be found and fixed

Brent Zundel: hopefully Mike can add his comments in IRC
… This is a valuable conversation, I’d like to come to some sort of agreement about it.

Michael Jones: In the IETF, it’s 100% clear that declarative sentences not using 2119 language are normative and testable. Yes - every statement is normative
… That was true when we wrote WebAuthn and WebCrypto as well
… There’s no reason to use 2119 language when a declarative statement means the same. That’s just spec bloat.
… Plain English is testable
… Adding 2119 keywords is unnecessary

Ted Thibodeau Jr.: I think what Mike is trying to say is that in IETF, they recognize that everything they say is meant to be authoritive and spec text, they don’t force themselves to use 2119…
… This is my opinion - what we’re doing here is different — we are trying to say everything said in 2119 language is normative, everything else is plain english.

Manu Sporny: there’s respec boilerplate that states everything in rfc2119 is normative

Ted Thibodeau Jr.: Yes, plain english is testable, please go through the spec to pick those things out — requires a lot of effort and we want something definitive.

Brent Zundel: https://www.w3.org/TR/did-core/#conformance

Michael Jones: Good - everything is normative

Michael Jones: That supports my point

Orie Steele: I am pretty strongly against “lets test all the english language in the spec”

Orie Steele: :)

Jonathan Holt: I sat down and did this in CDDL for the entire DID spec see: https://github.com/w3c/did-spec-registries/tree/master/cddl

Brent Zundel: We do say everything is normative — if there is a normative statement that we want to test, that doesn’t have 2119 language, it seems like there are folks in the group that want to add that language.

Michael Jones: Most of the plain meaning of the spec doesn’t use MUSTs - because you don’t have to

Michael Jones: We should still test all the normative statements

Ted Thibodeau Jr.: Testing all normative statements is one of our goals. Automated tools help in that, and have revealed some hundred+ such statements needing tests. After those are addressed, someone might be able to remove those statements from the doc, and read over the resulting output for normative statements that still need tests or rewording.

5. P2 issues

Brent Zundel: https://github.com/w3c/did-core/issues?q=is%3Aissue+is%3Aopen+label%3Apre-cr-p2+sort%3Aupdated-asc

Brent Zundel: https://github.com/w3c/did-core/issues/170

Brent Zundel: Public key ID and type members duplicate kid and kty members.
… raised by mike jones, good conversation, assigned to Mike Jones… can you give us a status update on this issue.

Michael Jones: I don’t think this has been resolved — no statement in spec between different fields that they must be equivalent or that you shouldn’t use one or the other.

Brent Zundel: ok, next step for this is for Mike to raise a PR that adds the language the spec should have or removes language you feel spec shouldn’t.

Brent Zundel: https://github.com/w3c/did-core/issues/58

Brent Zundel: Moving on to 58 — registry handling.

Wayne Chang: 58, registry handling — depending on where folks want registry — if you want it at CCG or not, fine either way, can facilitate either way — can try to decide now or continue discussion on thread, up to folks here.

Brent Zundel: we could have a special topic call on this at some point.. kinda wish process 2020 had incorporated registry plans.
… I am “preaching to the choir” — will add to special topic call considerations, thanks for update wayne.

Brent Zundel: https://github.com/w3c/did-core/issues/367

Brent Zundel: Next issue is 367
… Move issues from spec registries to DID Core, assigned to kyle, manu do you have an update?

Manu Sporny: Nope

Orie Steele: afaik its only https://github.com/w3c/did-spec-registries/issues/102

Brent Zundel: I’ll ping Kyle in the issue.

Brent Zundel: https://github.com/w3c/did-core/issues/363

Brent Zundel: issue 363 — clarify authorization requirements –
… raised by community member…

Manu Sporny: I believe I need to write spec text and have not done that yet
… there might not be, it’s on my list. Maybe I’ll remove the ready for PR flag and re-review and it will be closed if we don’t hear back and the editors don’t feel like more text is necessary
… Issue 439 - remove JSOn representaiton from DID Core

Brent Zundel: https://github.com/w3c/did-core/issues/439

Orie Steele: We are waiting for at risk issues to annotate the spec, then expect issue to be closed once we’ve marked it as at risk

Michael Jones: There is no reason for JSON to be marked as at risk because there are multiple implementations.

Drummond Reed: FYI, I’m adding one at risk annotation as soon as I can resolve a GitHub issue I’m having.

Manu Sporny: what are those implementations?

Michael Jones: I don’t have the list in front of me, but in conversations… heard of multiple ones.

Jonathan Holt: IPID can be represented in JSON

Orie Steele: I have seen no evidence of mikes assertions, and i am one of the editors of the registry that records implementations

Ivan Herman: We need to document these.

Michael Jones: This is a red herring, unproductive to mark something as at risk that’s a core feature.

Brent Zundel: If two or more known implementations of a JSON-only representation exists and we can identify them, we don’t need to mark it as at risk and we don’t need to mark it… but don’t know if two have been brought forward.

Amy Guy: also if the at-risk features get implementations during CR there’s no problem.. not a big deal?

Brent Zundel: https://github.com/w3c/did-core/issues/425

Brent Zundel: 425 — did spec registries needs terminological criteria…. this is an issue assigned to Joe Andrieu — update Joe?

Joe Andrieu: This is over my head, related to trademark disputes related to IANA — and we haven’t figured it out… risk of liability for registry editors and W3C for problems for registered terms and methods… we need to figure out how we’re going to resolve that.

Ivan Herman: Example?

Joe Andrieu: We don’t have guidance on trademarks….

Jonathan Holt: IPID can be represented as JSON — CBOR, multiple implementations using CBOR as well as JSON.

Drummond Reed: I didn’t realize it was this issue — revisit registry governance rules, can add that to my list as one person contributing to that.

Ivan Herman: I am not a lawyer, can’t comment in name of W3C… if problem/issue is clearly described, then we should ask W3C legal staff to look at this.
… I don’t think any one of us knows that.
… I have to go back to Wendy with something more specific.

Drummond Reed: I’ve worked w/ a number of lawyers on this issue - can help, yes it would be great to have W3C legal counsel input.

Ivan Herman: If you prepare something, I can ask Wendy.

Brent Zundel: Is more needed than what’s in Issue 425

Drummond Reed: I’ll take a look at it.

Ivan Herman: I’ll send this to Wendy and she can tell us if she needs more information or not.

Brent Zundel: Issue 240

Ted Thibodeau Jr.: I think the gist is clear in 425. W3 needs boilerplate for registries handled by all WGs/CGs/etc.

Brent Zundel: https://github.com/w3c/did-core/issues/240

Drummond Reed: Perfect, thanks Ivan!

Brent Zundel: Should DID Core restrict use of JWK? raised by Orie, assigned to Orie, Manu and Mike

Orie Steele: We had a number of special topic calls where we discussed this, primary consensus on calls was — no private information of any type should be in DID Documents, already have language in DID Core spec on that, not sure how much mroe specific we should get on JWK… other issues related to removing key representation specifics imply that these details should be in suite definitions, not in DID Core.
… As an engineer, I don’t want to redefine what JWK is in this spec.

Brent Zundel: Issue 163

Brent Zundel: https://github.com/w3c/did-core/issues/163

Brent Zundel: use of terms defined in specifications — we know we’re going to do it.
… Issue 325

Brent Zundel: https://github.com/w3c/did-core/issues/325

Brent Zundel: Rawsec 32 bytes — this is resolevd by same things that Orie talked about earlier.

Manu Sporny: proposal is to move those specifics into the linked data cryptosuite, what orie said

Brent Zundel: Thanks all for coming, thanks manu and amy for scribing, made good progress, bulk of work happens outside these meetings, move issues forward, if you feel need to contribute — ready for PR, people can grab, submit PRs for, feel free to do that… it’s an underrated thrill, dare I say
… Special topic call later today - 6pm ET.
… Thanks all!