DID WG Telco — Minutes

Date: 2020-12-01

See also the Agenda and the IRC Log

Attendees

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

Regrets:

Guests:

Chair: Daniel Burnett

Scribe(s): Kaliya Young

Content:

1. Agenda Review, Introductions, Re-introductions

Daniel Burnett: Close pull request 454 and focus on priority 1 and priority 2 issues.

2. PR 454

See github pull request #454.

Daniel Burnett: main item for today pull request 454

Daniel Burnett: Manu where are we

Manu Sporny: we are waiting for mike jones to tell us if he is happy with it or not

Daniel Burnett: we had some time waiting for proposals. should we move on to priority 1 & 2 issues and come back go 454 (10 min at the end)

3. Priority 1 Issues

Daniel Burnett: next item priority 1 issues

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

Manu Sporny: happy to go though them - did review of priority 1 issues
… sharing screen
… here are all the priority 1 issues - did review of them basically not much has changed since last week - (expected)

Daniel Buchner: The equivalence props are testable, and I will have a single page HTML page test today

Manu Sporny: Daniel there are three things we need to talk about one thing can resolve all of them
… 421, 368, 70 all canonical did/equivalent ID issues — we are close to merging the PR and there is one outstanding thing
… Daniel there is one remaining thing — you had put in some must language around relying parties — and it is questionably testable and we don’t know if we want to talk about that. I think you were concerned it is testable. Orie was like you write the test for it.

Daniel Buchner: it is testable and will be writing the test today.
… describes the test
… without the must language it is not reliable — start using the DID and a long time later when it has a simple form I can’t switch over to it. If I can’t rely on the fact that folks will recognize it — it effectively doesn’t exist.

Manu Sporny: sounds like a complex test -

Daniel Buchner: nope blank DID document that says primary ID — canonical switch

Manu Sporny: sounds really hard — we could mark it at risk.
… if you fail to read a test we have to go through another CR

Drummond Reed: +1 to merge and to mark at risk in case the test is harder than it looks.

Manu Sporny: as long as you do the work for it.

Daniel Buchner: many things in the document says things about how it should work. “this is used for this”

Manu Sporny: we are removing all the language that is not testable.
… we are trying to get very careful a about normative language

Ted Thibodeau Jr.: SHOULD != MUST among other things…

Manu Sporny: Must will have test for Should might have tests / judgement call

Daniel Buchner: Could we degrade to a should from a MUST

Manu Sporny: yes

Ivan Herman: I may mis-understand the discussion but it reminds me of a discussion. When a working group defines a vocabulary, what the CR phase means around vocabulary is unclear — you can not really test. But you can prove that a certain community uses those terms because it is a useful vocabularly item. Mere existence of a term used by other community may be ok for CR phase.

Manu Sporny: for CR its good enough to show that some people out there are using it (vocabulary)

Ivan Herman: the bar is different
… what you have here as a standard reflects what the community means

Manu Sporny: add a tag this must may become a should

Jonathan Holt: testability has to do with DID resolution — we aren’t there yet. getting to the point that did methods are testable at did resolution

Manu Sporny: with that merge we can knock out three priority 1 issues.
… everything left is grunt work — we need to specify serialization rules we have them for JSON and need to define for JSONLD and CBOR
… I’m wrong — there is this appendix: discussion w/drummond, joe, kyle
… are we making progress or do we need a special call on this?

Drummond Reed: don’t know that we need a special call — I’m trying to figure out how to respond to latest comments. Will figure out in next 48 hours and try to figure out what productively we can do about his comments.

Daniel Buchner: Aside: the WebID folks at Chrome have advanced the features to the next stage in Chrome’s dev stage and has a patch in for it: https://chromium-review.googlesource.com/c/chromium/src/+/2134202. This lays claim to navigator.id as an API area, and at present, really blocks out extensibility and DIDs. People should be active in their demands for changes to WebID interfaces and its overall scheme.

Manu Sporny: note to the chairs — everyone needs to start producing text they are going to be happy with. alternate PRs need to be raised or re-wordings need to be proposed. May need a special topic call on it.

Daniel Burnett: general objections are no longer ok.

Ivan Herman: be careful what you wish for — some comments are asking for changes all over the place.

Manu Sporny: those are the priority 1 issues and can move on to priority 2 issues.

4. Priority 2 Issues

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

Manu Sporny: priority 2 issues: start at the top. 1st one restriction of JWK - mike needs to weigh in.
… we have agreed that it should (restrict use of JWK) anything that is in private registry not appear in did document.
… still issues way we talk about keys in did core
… we define things in did core that should be in linked data proof and linked data signature specs <– just community group documents.
… problem putting it in did core is a layer violation — we can continue to do that but it is not very clear (in the VC spec pointed to other specs)
… tried to use this strategy in the did-core spec and we should normatively define in
… are people open to cleaning up and layer it

Drummond Reed: can I ask — what do you mean by add the layering

Orie Steele: See https://w3c.github.io/did-core/#key-types-and-formats

Manu Sporny: taking out all the specifics of how you express it. We just say if you are interested in expressing bitcoin curve key.
… instead of saying this is exactly how linkeddata proofs and work — point over somewhere else.

Orie Steele: I linked to the relevant section of did core — a couple open issues. Key type and support section — specific curves and public key list. We are doing a ton of duplicated work.

Manu Sporny: feels really sloppy — seems to imply the are the only key types that are supported although the registries.
… different keys define different types and that is all we should have to say did core

Drummond Reed: +1 to what Orie just said - does clean things up. Didn’t understand term layering the way manu did.

Ivan Herman: editorial comment — if I read the document, I will find in the examples with terms — e.g., key representation — must make clear which terms are defined normatively in spec and those defined somewhere else in a registry.

Manu Sporny: so where is the line — did core defines these today.
… point to other places — specifications and registries.

Ivan Herman: if you stay at that example block - id, type, controler are defined in spec but publickeybase58 is not defined.
… we need very clear list of what is defined IN the specification.

Manu Sporny: all true things and things editors would like to clear up.
… I expect Mike to object to this in some for

Orie Steele: we already agreed to define publickeyJWK and publickeybase58

Manu Sporny: for the item did core does define the left hand side but points to some things on right hand side that are used

Jonathan Holt: +1 to Orie, seems reasonable

Manu Sporny: only problem is that this belongs in security vocabulary
… what you suggested orie seems fine to me
… editors will put together a PR to make the layer cleaner (Mike might object)
… Orie could you do me a favor and summarize that as a next step in this item.
… horizontal review self test (its done)

Ivan Herman: its done

Manu Sporny: issue10 - left open for reporting.
… same thing for accessibility, issue 105
… next issue 325 has to do with the raw values for secp256 r1 - we are trying to figure out …this had to do with the rewrite - suggestion for this one is to remove the text or the JWK crypto suite to define this
… ivan - this one 404 - so we have to agree - what exactly we want to do. JSON schema CDDL - … I can’t decide what should be there. I came up with RDF vocab and SHACL - we have to define what exactly we want to do - maybe a special call - I woudln’t know what to do
… we are going to have did-core human readable. JSON LD context that defines URL -

Ivan Herman: you jumped ahead ahead a little bit

Manu Sporny: context defines some of the terms - reader doesn’t want to go down to the core - reader doesn’t want to look at JSONLD it is useless.

Ivan Herman: what are the terms that are defined - usable.

Orie Steele: so we did have some discussion about this on various different issues. this is the thing that bothers me and the relationship between registries and did core vocab.
… the specific separation of concerns did core spec, did core vocab and did core registries. Yes JSONLD - RDF and also plain english - machine and human readable definitions.

Ivan Herman: typical topic for special call.

Manu Sporny: not ready for PR need special topics call
… I think we need at least these things need to be defined.

Drummond Reed: +1 to special topic call on specifying the vocabulary

Shigeya Suzuki: +1 to special topic call on specifying the vocabulary, too.

Ivan Herman: I can make life easier with next two items (issues 401 and 403)
… amy did heroic work since I read this and the spec has changed a lot, and most of the comments there are editorial.
… I would propose to close both of those issues, and we should all do a thorough re-read of the spec before it goes to CR. I will certainly do it.

Manu Sporny: David, can we get a status on the information proxy type - if you can do anything it is going to go to registry
… closing issues
… orie issue 423
… issue 240 was already discussed
… will be closed when there is a PR
… 398

Orie Steele: as soon as we have the CBOR CDDL - in the security and privacy questionnaire.

5. Back to 454

See github pull request #454.

Ivan Herman: +1

Manu Sporny: we need a position on 454 my suggestion we merge it in - any changes mike wants can be made in a new PR.

Drummond Reed: +1

Drummond Reed: Agree with Brent.

Brent Zundel: essentially same things as manu - a number suggestions in the PR that are good faith efforts to meet mikes concerns those should be merged.

Daniel Burnett: I agree, as co-chair

Manu Sporny: editors can proceed.

joe: my question is address by drummond’s comment

Ivan Herman: Mike has arrived.

Manu Sporny: Mike, we’re discussing 454 with the changes that have been suggested would you be ok with merging the PR.

Daniel Burnett: chairs believe there is a good faith effort
… we are waiting on resolving your concerns

Manu Sporny: justin has attempted to add this additional language and defined terms
… context will be ignored, will not have additional processing

Michael Jones: is this the PR that deletes the text - we add other text to clarify what ignore means.
… all right it is equivalent to what we had before - well alright.

Drummond Reed: Yes, it is equivalent and actually clearer

Ted Thibodeau Jr.: note that the later note has a textual (and I believe editorial) tweak suggestion from me, which Github doesn’t track as such, because you can’t add a suggested change to a suggested change…

Manu Sporny: we added text around ignoring un-known properties - and it is more specific about what we mean. unrecognized properties will be preserved.

Daniel Burnett: we are at top of the hour. so we are done. There is a special topic call Thursday - complete security and privacy questionnaire.