DID WG Telco — Minutes

Date: 2021-05-11

See also the Agenda and the IRC Log

Attendees

Present: Brent Zundel, Ivan Herman, Markus Sabadello, Shigeya Suzuki, Ted Thibodeau Jr., Justin Richer, Adrian Gropper, Charles Lehner, Manu Sporny, Geun-Hyung, Drummond Reed, Daniel Buchner, Dmitri Zagidulin

Regrets: Daniel Burnett, Amy Guy

Guests:

Chair: Brent Zundel

Scribe(s): Manu Sporny, Adrian Gropper

Content:

1. Agenda Review, Introductions, Re-introductions

Brent Zundel: We’re going to talk about special topic call, brief section on status of implementations, we’ll do discussion on DID Spec Registries (clarifications of previous resolutions), implementation guide, and as time permits, finish off with any open issues and PRs for DID Core.
… any questions/additions?

Manu Sporny: None

Brent Zundel: foregoing intros/reintros because we all know each other well at this point.

2. Special Topic Call

Brent Zundel: The special topic call is today, Tuesday, 6pm ET
… The topic is “The Implementation Guide”
… any questions?

3. Status of Implementation Feedback

Brent Zundel: What’s the current status?

Manu Sporny: See link to the test suite

Manu Sporny: At present we have finished the tests
… We have sent a request out for implementations
… in the meantime, we have gotten a few implementations in already: https://github.com/w3c/did-test-suite/pulls
… We’re looking for more implementations, I’ve got a question for the group… is it okay if we just merge implementations immediately if they’re passing the tests?

Brent Zundel: Question to the group – any opposition to merge test reports as they come in as long as they’re passing?
… I’m not hearing any objections…
… if there is no opposition, seems like a good sense move to me.
… Has there been any help in doing the automatic report generation?

Markus Sabadello: Yes, I also think we should merge passing tests/implementations as they come in
… I’m not aware of any changes there.

Manu Sporny: we have had no automatic report generation
… we really need this done - we can’t tell how many features have been - we’re stuck - can’t get out of CR
… probably have enough for 85% of the spec but we’re blind and will keep us from getting out of CR

Ivan Herman: Manu, is there somewhere a clear description or something of what the automatic generation should mean?

Brent Zundel: report generation issue: https://github.com/w3c/did-test-suite/issues/78

Manu Sporny: there is not - we had calls - there’s some record somewhere - “the gratin of the report will take in everything and when we generate the report it will put the normative things down - Orie did some and it’s unsure if Orie will do it again

Ivan Herman: If it’s not a difficult task, it seems like you have to know knowledge about test suite
… It’s not like you’re processing a CSV file… that’s a much easier thing – you really have to know the testing inside and out.

Manu Sporny: Yes - you need to understand how MOCHA and ??? run and then the thing could be converted to CSV and then to ReSpec - and then figure out the matching rules for each one

Ivan Herman: Something more clearly defined might help.

Shigeya Suzuki: I’m wondering whether Orie will merge this PR: https://github.com/w3c/did-test-suite/issues/78#issuecomment-830204485

Manu Sporny: I don’t think we’re going to get there - will take one or two hours

Brent Zundel: to sum up, in order to exit CR, we need to know how many implementations of each feature are going to be submitted in order to automatically generate that report – a manual painstaking process without automatic tabulation. We are still seeking volunteers to help with that work. If you have willingness and time, there are some links in the issue that can give you the guidance you need to get started.
… Any other questions/comments before we move on to the next topic?

Shigeya Suzuki: I do not understand the patterns of the test runner – the link I posted, Orie’s comment, he mentioned that one PR never got merged into the test suite.
… This solves part of my … missing part of my understanding of the test suite – will this change be merged?
… I don’t know if it’ll be merged or not.
… I can’t say if I can contribute or not because of this… once I can generate with latest branch then I can estimate how much I need to spend there… I can contribute I think.
… That’s a blocker to contribute at this point for me.

Brent Zundel: https://github.com/w3c/did-test-suite/pull/20

Brent Zundel: This is high priority for us… what would it take to merge this PR?

Manu Sporny: I think we need to move past this PR… it’s old and has conflicts and there is frustration around the PR

Markus Sabadello: I think there was something wrong about JSON vs. JSON-LD representations, but there is a lot that seemed perfectly fine, huge PR, did a lot of things… I did disagree with one small part of it, but not other parts – I don’t remember this in detail, not fully understand what’s missing now wrt. what’s missing for generating reports… don’t understand what’s needed from that previous PR right now.

Ivan Herman: practical issue, PR against master branch which we do not have any more. I can’t remap the PR… this PR seems lost in any case.

Justin Richer: It’s simple enough to create a new PR with this branch as it is, retargeted towards main, if someone thinks it’s worth pursuing it can be done.

Brent Zundel: If there are no more comments/questions, let’s continue.

Shigeya Suzuki: I think I can look at the PR and grab part of the initial functionality to create an initial PR… I’ll ask Orie if it’s ok to merge PR into the repository

4. DID Spec Registries

Brent Zundel: We made a number of resolutions about the registries.

Brent Zundel: https://github.com/w3c/did-spec-registries/issues

Brent Zundel: The issues have not yet been acted upon… so we’re going to go through the issues at this point.
… If you follow the link, you will see 76 open issues on the registries… that’s a lot
… We have proposals and some resolutions that we need to look at, so, stabbing at random.

Manu Sporny: background: we had made a number of resolutions to remove, for example, the CDDL stuff, as a requirement for registration - it fell out of alignment with the specification - Orie put a PR to remove CDDL
… but JSON Schema was also removed and the PR was closed - Orie was acting on a resolution that the group made - so now we need to make a new try to remove CDDL -
… suggestion: let’s remove CDDL but without JSON schema being caught int he cross fire
… do you want me to author a Proposal?

Brent Zundel: yes
… Let’s have a proposal…

Proposed resolution: CDDL will no longer be required for registration of items into the DID Spec Registries. All current CDDL will be removed from DID Spec Registries. (Manu Sporny)

Ivan Herman: +1

Brent Zundel: +1

Drummond Reed: +1

Manu Sporny: +1

Adrian Gropper: +1

Shigeya Suzuki: +1

Dmitri Zagidulin: +1

Charles Lehner: +0

Drummond Reed: Just wanted to ask, if we’re also going to get to discuss idea of adding a table w/ DID Methods indicate where representations they do support.

Markus Sabadello: +1

Resolution #1: CDDL will no longer be required for registration of items into the DID Spec Registries. All current CDDL will be removed from DID Spec Registries.

Manu Sporny: the next one is removing JSON schema in DID core as well. It is required for registration -or - we publish a JSON schema that you can run against -
… I will make two proposals

Ivan Herman: If one item has a JSON Schema, it will lose it – have a slot in registry where people can voluntarily add their JSON Schema would make sense, not require it.

Drummond Reed: +1 to supplying the normative schemas in the referenced specification — which is NOT optional

Manu Sporny: I get where you’re going - but it would complicate the registry - people should put it in their specs - we would add language to put it in your spec

Ivan Herman: I am o.k. with that

Drummond Reed: That’s the second reason – what is in the registry – surface just the MIME types that your specification supplies the schema for… indicate in a table what to do.

Proposed resolution: JSON Schema will no longer be required for registration of items into the DID Spec Registries. All current JSON Schema, except for the one pertaining to DID Core, will be removed from DID Spec Registries. (Manu Sporny)

Ivan Herman: +1

Drummond Reed: +1

Manu Sporny: +1

Adrian Gropper: +1

Brent Zundel: +1

Dmitri Zagidulin: +1

Charles Lehner: +00

Markus Sabadello: +1

Shigeya Suzuki: +0

Resolution #2: JSON Schema will no longer be required for registration of items into the DID Spec Registries. All current JSON Schema, except for the one pertaining to DID Core, will be removed from DID Spec Registries.

Manu Sporny: we just passed we will do a JSON Schema for DID Core

Ivan Herman: The current JSON Schema will become out of date as soon as you change the publicKeyBase58 thing, I will do those changes once it’s in Core.

Manu Sporny: This is the last one: We’re trying to get DID Spec Registries easily maintainable - When you register things: you put the item in, you point to the spec and as Drummanod says - put in the entries in a format to be changed

Drummond Reed: Just wanted to point out that – the benefit is that it surfaces in the registry for prospective users of extensions to understand what’s supported… some peer pressure to support more representations. Easy thing to check. Not required that maintainers verify that all those schemas / representations are valid… just that it’s there in the spec.

Markus Sabadello: I don’t understand at all what it means for a property/extension to list what MIME types it supports – whole idea of production/consumption is to support lossless conversion between all registered properties… if we now suggest that some mimetypes are supported and some are not … it contradicts purpose of the abstract data model.
… I do understand that not everything needs CDDL / JSON Schema, that’s good… but concerned about things like additional representations defined in future, people shouldn’t have to update their extensions/properties to make them work with their new representation… should be automatic implication of data model and registries

Drummond Reed: That’s true, purpose of MIME types for schema support is to indicate that they have done that – that doesn’t mean that’s the only thing they work in… we would make that clear in the text – this is to encourage specification writers to support schema support for different representations, not required for them to do that.

Ivan Herman: Mine is a minor point – we still do not know what the MIME type is going to be, we don’t want to make life difficult for registry maintainers… JSON/JSON-LD, that’s all.

Manu Sporny: agree with markus - the problem with registries happens when the information goes out of date - the second a new representation is created (e.g. CBOR-LD)
… the second item: it’s not clear that the field doesn’t achieve what Drummond is trying to do - we don’t want to say that some properties only work in some representations - we already have an ADM -
… we don’t want people to be confused about the role of registration

Markus Sabadello: Could the field be named differently, propose to avoid language to avoid “supported representations” – supported mime types, field could be linked to JSON Schema if available – link to CDDL if available

Drummond Reed: I wouldn’t have called it supported – we want spec authors to provide schema support for different representations.
… Easy way for folks perusing to say which specs have schema support for new representations – as specs are updated, those that choose, CDDL Schemas to spec… if it’s not of enough value, too much value, let’s forget it. The idea was keep schemas out of registry, idea is which specs hav them and which ones don’t.

Manu Sporny: I totally misunderstood your proposal:
… you’re saying: provide a box that says my spec is here and my spec defines CDDL and JSON Schema which has nothing to do with mime types

Adrian Gropper: Drummond agrees

Justin Richer: I share Markus’ concern, wanted to propose something along the lines of what Drummond is saying, but perhaps more generically useful – one of the goals of production/consumption is to allow explicit mapping of representation types/property identifiers, forget specific term we settled on… whole idea was to allow property to be defined that it always maps to a specific abstract data model data type and property name and optionally has a

Manu Sporny: property-specific translation to a representation-specific data serialization

Justin Richer: and a property identifier – the idea here was to allow a property to be defined in such a way to be defined – this property has this property name, JSON-LD has context, has this registered CBOR tag value and so on but also allow you to say this property has this property name and this abstract datatype and everything should still work.
… All representation are required to have default rules when something more specific isn’t available.
… As a consequence, I agree with removing a requirement, but I disagree with a place to put it… but several steps past what Manu was saying as an interpretation of what Manu was saying.

Manu Sporny: mate close off registries - do not make people read every spec that is in the registries - the easiest thing would be tell us what you’re registering and then point to the spec - this makes it easy to maintnain

Justin Richer: maintaining registries is difficult which is why IANA is a fully staffed professional organization dedicated to doing that. 🤷‍♀️

Manu Sporny: the same thing could come into play as the CDDL problem -

Markus Sabadello: But a JSON-LD context is still required, or..?

Manu Sporny: there is a cost to adding useful information to the registry

Drummond Reed: This is fairly short – there is a happy medium, we want to keep the burden on registry maintainers as low as possible.
… I like Justin’s idea, maybe it comes down to 3rd column… guidance on providing essential information about your spec that you want to make easily visible, and we don’t get highly prescriptive about what’s there… you might list schemas you provide, types of things Justin covered, information covered by registrant…

Justin Richer: my prediction: an “other” field will just collect garbage over time if it’s not structured.

Manu Sporny: I agree with justin_r – it’ll end up being a dumping ground :/

Justin Richer: @manu you did not say that out loud :P

Brent Zundel: We look forward to seeing you at 6pm, pleasure working with you, see you later.

Ivan Herman: rrsagent draft minutes

5. Resolutions