DID WG Telco — Minutes

Date: 2020-12-15

Attendees

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

Regrets: Daniel Burnett

Guests:

Chair: Brent Zundel

Scribe(s): Jonathan Holt, Amy Guy, Manu Sporny

Brent Zundel: agenda…..
… special topic call, dagCBOR, DID core vocabulary. then discuss issues staring with priority 1 then 2.

Amy Guy: take 2 minutes to discuss TAG election.

Brent Zundel: next special topic registry handling, on Thursday the 12/17 12pm EST.

Amy Guy: TAG has an election coming up. The TAG is a architectural group..
… I’m standing in this election as is Wayne..
… my background is in open data and I’m hoping to represent that community..
… if you are an AC rep, encourage you to vote..
… the election is through the 5th of Jan.

Amy Guy: TAG nomination.

Wayne Chang: My statements.

Amy Guy: My statements.

Wayne Chang: List of AC members.

Wayne Chang: i want to express my support, there are multiple seats open including possibly both of us. I can provide a link to find your AC rep..
… there are a lot of interest in VC and we could build that bridge..

Manu Sporny: that is awesome that they are running..

1. dagCbor.

Brent Zundel: https://w3c.github.io/did-core/#dagcbor.

Manu Sporny: check in with jonathan.
… CBOR is in! wow-ho!. we have made some update to make it inline including production and consumption..
… mostly asking about canonical. then there is a section on dagCbor. I don’t remember if we have consensus?.

Jonathan Holt: The section I put for canonical focuses mostly on DAG CBOR section, you need it in a deterministic canonical format… CBOR spec does give guidance, but it’s not set in stone, it’s up to app developers like our specification to decide what is canonical. Nuances of lossless conversion in/out of dat model… that’s an additional constraint..
… I put everything I could think of to make it canonical, very involved in IPLD / IPFS community, been working ont hat for years – how to make sure it’s as deterministic as possible… they have a billion dollar industry to make sure things are deterministics - making sure it’s working as intended. Most issues are in numbers, JSON, 53-bits vs 64-bits, since we’ve dropped numbers, bigint, bigfloat, not an issue that will pop up right now for canonical deterministic – deterministic ordering of map - order right way, get different hash, really important..

Orie Steele: See also https://tools.ietf.org/html/rfc7049#section-3.9.

Jonathan Holt: wrt. production/consumption rules – consensus on DagCBOR – suppose section on deterministic representation has more to do w/ DAG section, I certainly am heavily into DAG, lightweight approach to blockchain..
… I think we do have a lot of consensus on worth of this approach, lot of work done in CG… multihash/multibase/hashlink in DID URL this community is invested in that technology.
… DAGCBor is extension of hashlink – rather than URL can be a type in DID Document… this probably needs to be worked out in DID Spec registries, can push DID Spec registries back into DID Core to get more cohesive support for it..
… How to build out extensibility… DAG CBOR extension to CBOR.

Daniel Buchner: manu, wrt your latest comment in effort to resolve the serviceEndpoint value, the LinkedDomains SE will need to require that the values are only parsed as origins, in the form defined by the HTML spec and its same origin model.

Daniel Buchner: manu, if we remove objects as a valid value, the one thing that could bite us is instances where a Service Endpoint needs to have other values outside of the URL - where would a SE put those values?.

Orie Steele: I have support for CBOR, I want to make sure that doesn’t cap us for vanilla cbor..
… Generally supportive of CBOR, need to do that in a way that doesn’t cap us – added support for vanilla CBOR to did:key that supports vanilla CBOR (What you get when you call CBOR.encode() on DID resolution).
… vanilla CBOR is what you get when you convert. our implementation of did key and CBOR..
… when you talk about CBOR, the is an RFC. dagCBOR is a document. i’m not sure about the sub-types..
… i’ having trouble understanding how we support them in the DID spec registries..
… I can only do so much for the CBOR section..

Manu Sporny: the concern I have is calling something canonical form is that you have some mathematical form. I don’t think we have that..
… having spent the last 7 years to get the JSON-LD stuff, it is hard..
… dagCBOR, i agree with Orie that we can do this in DID spec registries. we need to address. pushing canonical out and dagCBOR out as another representation..

Michael Jones: canonical is in the RFC, we ….

Orie Steele: whats in the cbor spec is not dag cbor, fyi.

Manu Sporny: it is definitely not defined in the CBOR spec.

Manu Sporny: reference to “canonical” in the CBOR spec.
“Those protocols are free to define what they mean by a canonical format and what encoders and decoders are expected to do.”

Manu Sporny: this is shaping up to need a special topic call..
… protocols are free to define what they mean by canonical..
… needs more discussion..

2. DID Core vocab

See github issue #404.

Brent Zundel: this was raised by ivan, folks have commented.
… we have 10 minutes or so to talk about it.

Manu Sporny: ivan this is mostly, the question to you - what are the expectations here?.
… we’ve had discussion, the core thing we’re trying to get to is we need a formal RDF vocabulary for DID core.
… what I want to make sure is that we’re all aligned on what we need to do to make that happen.
… we’ve got a human readable part of this which is the registries to a certain degree, it doesn’t have rdfa.
… the expectation is that we will probably have some rdf schema definition somewhere.
… I believe that’s primarily what you’re asking for?.

Orie Steele: Some related conversation on this dead PR.

See github pull request did-spec-registries#170.

Orie Steele: I linked a PR. I had a conversation with amy related to this on the did spec registries.
… it’s a PR for a thing that’s probably not going to get merged but there’s good conversation on there.
… my initial proposal would be lets set up the html side of the vocab definition the same way activitystreams have (see thread) and suse the DID spec registries repo for it for the time being, and work towards getting stable urls behaving in the way we want them to, and then work on setting up proper redirects for the vocab after that.
… from the perspective of what is needed, it’s a versioned html and jsonld files and I think we can do all that in the did spec registries and work towards a working solution there before we worry about fixing the top level urls.

Ivan Herman: I was probably not clear in what I wrote, but manu, unfortunately, this is not what I meant.
… forget about RDF.
… I used RDF as an example simply because that’s what I understand well.
… the problem is that if you read the document you have a bunch of properties that are defined there and it is not really clear .. two things.
… one is (maybe it has improved) what are the properties and classes that are defined as part of the core standard and what are there as an example.
… I have said that many times.
… and it hasn’t been clearly spelled out somewhere.
… and what is even worse is that there are a number of constraints that are not clearly spelled out for the reader.
… the various examples is on the top of my head the id property which in some cases can have only this and this values and in other cases can be used with different values, sometimes only did as a value, some cases you can use whatever url you imagine.
… there are the property controller which can be used on some types of objects and cannot be used somewhere else, what do they mean.
… there is a set of clear definition and constraints that are missing.
… hard to have those constraints spelled out as part of the spec is largely an editorial thing.
… what I did was spell out those constraints for the RDF side by using shacl and I realise that this was more an exercise for myself because you don’t necessarily know shacl.
… in a way what I saw done by jonathan for cddl is doing something very similar.
… I am not a real expert in cddl but what I understood is describing more or less the same things.
… I don’t care in which format we do that, but the spec must be clear.
… in my reading it is not..
… Apart from that (second issue), yes we define a vocab for the usage of RDF and linked data and yes for that we should have a formal vocab that describes the vocab in terms of rdf.
… that is not the same as the context file.
… it’s a RDF specification or something.
… that is something that should be done, it is not necessarily part of the spec, not normative, should be present and reachable, that’s something we can do very easily once the spec is out.
… that’s okay, that’s not the real issue.
… the real issue for me is the proper specification.
… I think that amy began to think about doing some kind of table representation of the terms to express the various constraints.
… that can also work for me.
… it’s up to the editors.

Manu Sporny: that is helpful, thanks ivan.
… there are a couple of things that have happened since your review that have improved things.
… we’re in the process of really nailing down the ADM and the representations, so hopefully it’s far more clear what you can have associated with each property across all representations.
… that’s one level of improvement, not done we need another pass.
… hopefully that addresses one of your main concerns.
… the other thing we’ve got now, jonathan put all that work into the cddl stuff os we have a syntax enforcement mechanism now for things that support it, like json, jsonld and cbor.
… we have that shacl/json schema mechanism but in this case we’re using cddl to do that.
… the third thing we have are the jsonld contexts which are in flux but we’re getting them shaped up.
… the only missing item is a good rdf vocabulary.
… something that more of the Semantic Web folks could utilise.
… and we should probably look at gregg kellogg’s tool that converts csv files into full blow human readable vocabs plus the rdf schema stuff in turtle format and whatever different formats we want.
… I feel like that’s the last missing thing.
… that can be autogenerated into the RDF things.
… with all of those things in place my hope is it addresses all the concerns you raised.
… I just don’t know if it would.

Ivan Herman: See Draft RDFS Vocabulary.

Ivan Herman: See Draft SHACL version.

Ivan Herman: as I said I am perfectly fine to use cddl for that. If that’s the way we do it, that’s fine..
… the only question I have and maybe it’s an obvious answer, is the cddl part of the normative spec?.

Manu Sporny: no.

Ivan Herman: it should be.
… that’s the major point.
… it’s the definition of all the constraints in a clearly defined way.
… this is one point.
… the rdf vocabulary I did something back then which is already on our wiki page. this has to be updated because we don’t have the whole thing.
… it was not perfect at that point.
… but that is there and as I said if the cddl is normative then this rdfs vocab doesn’t have to be normative.
… it is perfectly fine to have it .. it should be properly doen but it’s not something that holds up the CR.
… and we can start if from there.

Jonathan Holt: the cddl spec itself is normative and it extends the abnf rules, it is a normative description of the constraints and type definitions.
… which is what I think the rdf attempts to do with symbol representation for concepts.
… as ascii strings, it representation something.

Manu Sporny: Editor’s note: It is not normative right now… it would take a lot of work to get it to be normative..

Jonathan Holt: I think cddl tries to not boil the ocean in that way, it really is a constraint satisfaction which is mathematically proven.
… you can do the closures to make sure it captures everything you hope.
… I’ve demoed that before.
… you can generate examples using cddl which I’ve found really helpful.
… cddl does have a lot of power to help along the spec and really help constrain it into what types are allowed.
… as we’ve been finding there are some challenges when you go into an abstracted version of that.
… still a challenge with numbers.
… the number representation in ipld is still challenging to represent when you have limitations with certain representations.

Michael Jones: I push back on the idea that rdf is necessary or even useful.
… if we do that it would be one more parallel representation of what we already have normatively in the spec.
… if we believe the spec is not sufficiently clear in places that ivan described we should make the spec clear.
… we shouldn’t fall back to trying to maintain and create a separate parallel representation of the spec.
… I think we should do no rdf work.

Brent Zundel: if we could have those comments occur in the issues I think that would be best.
… issue 404.

3. issue processing.

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

Brent Zundel: these are priority 1 issues.
… a few we’ll go through pretty quickly.
… 118 we’ll do before CR.
… horizontal review tracking is an open issue 292 to track the various horizontal reviews, will stay open.
… 119 is about discussion with the TAG.
… thank to the group we now have a security and privacy questionnaire, the chairs will send it on to TAG and PING.
… and for those reviews to progress.
… I can comment on this issue.
… number 384 is next.

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

Brent Zundel: review of all of the normative statements in the spec.
… the status is the same as last week, addressing this issue requires tests to be written.
… encourage folks to review this issue and while they review it allow the scope of normative statements to spur them to contribute to our test suite.

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

Brent Zundel: next is 199, clarification of what DIDs might identify.
… I raised this and am assigned to it, so taking off my chair hat.
… the status is that there is an open PR.

Brent Zundel: https://github.com/w3c/did-core/pull/480.

Brent Zundel: the PR is 480.
… there has been some review but there needs to be more.
… please review that PR.
… and give your opinions there.
… chair hat back on.
… next is 291.

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

Brent Zundel: PING horizontal review.. I believe Orie asked if we can check this box and I’m going to check the box!.
… next, 464 was raised by orie and is assigned to him.

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

Brent Zundel: did core must define how to compute the digest to secure DID spec registries entries contexts.

Orie Steele: there is a PR open for it.
… hopefully it’s linked there, please review that.

Brent Zundel: https://github.com/w3c/did-core/pull/485.

Orie Steele: the tldr is if you’re going to tell people that content digests are somehow going to help protect them you’re going to have to describe how to use that.

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

Orie Steele: our next issue is 498, datetime data type missing timezone and precision, raised by manu.

Manu Sporny: we are trying to again get very specific with the ADM and the representations and we just didn’t specify that you need to express eerything in zulu time and we didn’t specify the precision that you should express datetime values in.
… the suggestion is not to do millisecond precision.
… if people want that they can do something else, you can extend it o you can do that.

Brent Zundel: ready for a PR?.

Manu Sporny: yeah, a simple thing, I just wrote it down to make sure we were tracking.

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

Brent Zundel: next 499, metadata properties don’t define data model and serialisation format.

Manu Sporny: this is to track the last item that justin had raised on the we need a better data model.
… justin pointed out we need to spec what the values space and lexical space of all these times are.
… those same things need to apply to the metadata properties.
… we’ve updated to be clear about the core data model and the representations but we haven’t one the same work on the metadata section.
… that’s a straightforward PR to write.

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

Brent Zundel: next is 58, registry handling.
… we are having a special topic call on this issue this coming Thursday.
… if anyone would like to comment on it now they can but I’m happy to move on.

Orie Steele: please review all of the issue that have discussed this before the meeting on Thursday.
… there has been a lot of talk about this.
… if you show up on Thursday having not reviewed the issue I will personally be disappointed in you..

Brent Zundel: i second that.

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

Brent Zundel: next 170, this is public key id and type members duplicate jwk kid and kty members.

Proposed resolution: close this issue. (Orie Steele)

Brent Zundel: now assigned to selfissued.
… the last time we talked I belive you agreed that if text needed to be changed you would write a PR for that.

Michael Jones: I’ve had other things to do.

Brent Zundel: understandable, thank you.

Orie Steele: selfissued, please also review https://github.com/w3c/did-core/pull/490.

Orie Steele: its related.

Brent Zundel: issue 240, should did core restrict the use of jwk.

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

Brent Zundel: assigned to manu, mike and orie.

Manu Sporny: there’s a PR that orie wrote that addresses this by saying don’t express private properties in a DID document.
… once that PR goes in I expect that can be closed.
… pr 490.

Brent Zundel: looks like pr 490 may address this issue and the last ne.

Manu Sporny: specifically mike jones needs to review this PR because it modifies a section fairly heavily. My expectation is you may have concerns, but it seems like the rest of the group is more or less okay with simplifying that section.

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

Michael Jones: OK - I’ll read 490.

Brent Zundel: 325, rawsecp256r1 public keys…

Manu Sporny: this is fixed in 490 as well, we are just taking those details out of the DID core spec, we never should have been talking about the purvue of a cryptosuite.
… that is once 490 pulled in we can close this issue.

Brent Zundel: sounds like quite a few issues riding on 490, please review.

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

Brent Zundel: now moving from p1 to p2 issues.
… first is 163, use of terms should be linked to definitions, will be done just before CR.

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

Brent Zundel: next is 208, the ietf did+ld+json media type registration.

Manu Sporny: we haven’t got ietf to review the proposal that amy put in.

Brent Zundel: still waiting on that, but am I remembering that we have contingency plans in place in the event that review does not occur in a timely fashion?.

Manu Sporny: yes it’s at risk, may change.

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

Brent Zundel: 363, clarify authorization requirements.

Manu Sporny: on me, haven’t done it yet. will probably happen towards the end in an editorial pass.

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

Brent Zundel: number 425, did spec registries needs terminological criteria.
… I’m hoping that this issue is part of the conversation on Thursday.
… not seeing Joe on the call today.
… ivan was going to contact wendy?.

Ivan Herman: I put the comment in the issue from Wendy.

Brent Zundel: she suggests we describe the criteria and who the arbiters of the criteria are.

Ivan Herman: she also had a remark that she doesn’t see any problem with the trademark part, the namesquatting and other things yes, but with trademarks we don’t define any of those terms we just put it into the registry.
… trademark problem doesn’t seem to be the problem.
… the real thing is to have a mechanism whereby eg. racist terms are not added.

Brent Zundel: hopefully Thursday we will have time to get some resolutions on that.

Ivan Herman: i didn’t look at the iana protocol registry, it has a long description of what has to be done to avoid these things, maybe we can refer to that.
… somebody who is ore familiar with this should do that.

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

Brent Zundel: next is 453, the relationship between VDR and DID Doc haven’t show in figure one, raised by shigeya.

Manu Sporny: the diagram just needs to be updated, minor editiroal fix.

Brent Zundel: ready for PR?.

Manu Sporny: yes.

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

Brent Zundel: last issue, naming classes of properties and syntax, 463 by markus.

Markus Sabadello: we’v emade great progress on the ADM there is representations on production and consumption rules, there are some inconsistent terminology around properties and representation independant things and representation specific properties so this issue is to track that and harmonize the occurance of the different terms related to properties and syntax thorugh the spec.
… there’s a diagram that shows what I understood was the consensus at tpac in terms of how to name these buckets, so please have a look.
… could use an editorial pass to make sure we use the same terms everywhere.

Brent Zundel: is this editorial?.

Markus Sabadello: I think so.

Phil Archer: Just as aside, I published an update to the UCR yesterday. From POV, I’m close to declaring ‘done’ :-) https://www.w3.org/TR/did-use-cases/.

Brent Zundel: thank you for coming everyone!.
… we are making progress, please come to the special topic call this thursday, about the registries.