DID WG Telco — Minutes

Date: 2021-04-06

See also the Agenda and the IRC Log

Attendees

Present: Ted Thibodeau Jr., Daniel Burnett, Chris Winczewski, Amy Guy, Geun-Hyung Kim, Shigeya Suzuki, Charles Lehner, Ivan Herman, Markus Sabadello, Kelsey Rhoda, Dmitri Zagidulin, Justin Richer, Adrian Gropper, Kristina Yasuda, Drummond Reed, Jonathan Holt, Daniel Buchner

Regrets: Manu Sporny, Brent Zundel, Dave Longley

Guests:

Chair: Daniel Burnett

Scribe(s): Markus Sabadello, Amy Guy

Content:

1. Agenda Review, Introductions, Re-introductions

Daniel Burnett: today’s call will be about W3C Notes we will be working on. Then we hope to get an update on DID Rubric, and status review of DID Rubric.

Daniel Burnett: Anyone joining for the first time? Anyone want to re-introduce?

Daniel Burnett: Maybe Adrian?

Adrian Gropper: I am around as Invited Expert on privacy and community issues. I’m volunteer CTO of Patient Privacy Rights, and also lead of a reference implementation of some of the SSI stuff, called HIE of One.
… One of my immediate goals is to harmonize IETF GNAP with data models of VCs and DIDs.

2. Special Topic Call

Daniel Burnett: Special topic call will be on Thursday at noon US Eastern.
… This will be a test suite working sessions.
… Also if you’re in the process of writing tests and need help
… Last session on test suite was quite productive.

3. Additional Notes

Daniel Burnett: We have two WG Notes: 1. DID Rubric, and 2. Implementation Guide.
… There is a first draft of the Rubric document. I believe something has come in for the Implementation Guide.
… People have expressed interest in the Imp Guide, need a draft by end of April.
… If we do not have a first draft by end of this month, then as a WG we will encourage not to produce something.
… We haven’t agreed on the PR as first draft, but there’s some text to look at.
… If you have any opinions, now is the time to contribute.

4. DID Rubric status update

Daniel Burnett: Anyone know the status of the DID Rubric?

Dmitri Zagidulin: I know that Joe &co are actively working on it. I reviewed one of the drafts. It is in progress.

Daniel Burnett: But it’s still not a first draft?

Dmitri Zagidulin: Reach out to Joe, it might be ready for that.

Daniel Burnett: We’re at a point where it has to officially move into the group and become one of the WG items.
… Otherwise we won’t have time for the group to work on it.

Dmitri Zagidulin: Do you mind emailing Joe?

Daniel Burnett: The chairs will follow up on that.

5. Test Suite status review

Markus Sabadello: I was on the last special topic call where we made a lot of progress, merged all the PRs
… people have contributed a lot of work, multiple people have contributed not just one or two
… the PRs that have arrived pretty much cover all of the spec, or almost all of it
… what has to happen now is some restructuring and harmonisation because different test implementers because people have approached it differently
… and there’s a certain amount of duplication
… there could be code reuse
… that is expected at this stage
… it’s looking good
… now just about deduplicating things and getting the test suite into a structure that works for everybody
… I don’t think it’s quite ready yet for did method implementers to submit their data or results
… because there is this restructuring going on
… but almost ready

6. DID Method Implementations

Daniel Burnett: There is some refactoring that still needs to happen.
… This is not a call for implementations yet, this is a call to get ready.
… Once the refactoring is done, we will be asking implementers to submit their reports.
… Anyone planning to submit, please mention it in the chat.

Dmitri Zagidulin: +1 impl report for did-key, did-veres-one and did-web

Daniel Buchner: Microsoft will submit, possibly in coordination with other Sidetree implementers

Markus Sabadello: manu did create a PR to do this refactoring or part of it
… not merged yet
… can’t say if after that PR we’ll be ready for data
… but that work is happening to this refactoring
… the second comment is that the idea is that there could be multiple types of implementations that can be submitted
… so you don’t necessarily have to implement your own did method, you can also test implementations of other parts of the spec
… producers, consumers, parsers, resolvers
… the idea of the test suite would be that you can submit implementation reports for those things even if you don’t implement your own did method

Daniel Burnett: dbuc, do you know what you are planning to support?
… e.g. are you planning to submit implementation support for JSON

Daniel Buchner: We’ll support both.

Daniel Burnett: That’s helpful, we were not sure if we will get enough implementations of JSON.

Charles Lehner: +1 Spruce to submit an implementation report, possibly including did:tz, did:key, did:web, did:onion

Daniel Buchner: JSON, by way of doing basically nothing to the JSON-LD variant

Daniel Burnett: We need to cover all of the tests, this includes the various implementations.

7. Test Suite Issues

Daniel Burnett: As chairs, we wanted to go over test suite issues, and DID Core issues.

Daniel Burnett: https://github.com/w3c/did-test-suite/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc

Markus Sabadello: we can go over the 10 open issues

7.1. Missing tests in DID Resolution and DID URL Dereferencing

See github issue did-test-suite#53.

Markus Sabadello: the first one I raised. I submitted tests for did resolution and url dereferencing sections, which have bene merged
… this issue tracks sentences in those sections that are not yet covered
… eg. in did core there’s a statement that says a conforming did method spec must guarantee that each equivalent id value is logically equivalent to the id property value. Not sure if this is testable at all
… that’s what this issue is about

Daniel Buchner: we had one we were taking about in a PR that we were going to mod some language..
… did we decide if we’re going to accept… the equivalent stuff the method defines.. there are ways inside methods to figure this out
… can we accept a test where an implementation test takes in a did and says I’ve got an equivalent and id property, I’ll save both - test success
… is that acceptable?

Markus Sabadello: I don’t know, the did core spec says a conforming did method must guarantee that some identifiers are logically equivalent. I don’t know how to write a tests that tests that the did method spec guarantees that

Daniel Buchner: it would happen inside.. i don’t know that the external thing would be testing that
… eg. the did spec says the did method should determine the correct keys to put in the did doc.. I don’t know how it’s doing that, we can’t test inside all the methods how they’re doing that.. grabbing keys and sticking them in a json object.. but because we tell them they output the correct json doc we assume they get the correct keys

Daniel Burnett: if you join on Thursday that would be a great time to discuss the topic

Daniel Buchner: okay

Daniel Buchner: I am, will do

Daniel Burnett: and you were also signed up to write some tests? good chance to talk about that and the question

Markus Sabadello: this is one case where I just didn’t know how to write a test, maybe someone can help in a working session

Daniel Buchner: I don’t think there is a way

Markus Sabadello: that might occur in several more times
… we discover some statement where we don’t have a way of testing it in an automated wya
… not sure then what we need to do
… we’ve had discussions a few times if you can still have normative statements in the spec without testing them in an automated way
… in that case they’d have to be demonstrated in some other way that it is possible to implement them
… we’ve had those discussions, manu and ivan know better how that works
… if we can’t demonstrate that it’s possible to implement then the alternative is to not use normative language
… and just say did methods are expected to guarantee that instead of saying MUST
… other people know better what to do in these cases

Daniel Buchner: DID Key and some other initial state long-form type DIDs are really the only ones you could ‘test’ if they have included the correct keys

Daniel Buchner: DID Key is a key, so obviously you can know what the right key should be

Daniel Buchner: But any method that has had a rotation occur forms the correct key associations internally

Daniel Buchner: so that’s always going to be specific to the method

Daniel Buchner: as everything in the DID Doc is

Daniel Buchner: including Service Endpoints

7.2. How will be produce visualization of the test results

See github issue did-test-suite#51.

Markus Sabadello: I’m not familiar with this one, self describing
… test report in the form of a json file
… a number o fways of how to render that in html

Daniel Burnett: even though we don’t have a notion of editorial with the test suite, this falls into that category
… presentation, not about the actual running of the tests
… in the end orie will decide something but if you have an opinion, express it

Ivan Herman: we discussed this with orie on the last call
… we will have to produce some sort of report of the whole CR phase, test results, implementations, etc
… there are other examples in other WGs
… I can help with that at the end
… the only thing it affects right now is that there should be a clear structured way of characterising each test
… metadata about the test
… and about the implementations
… once those are there in some format, whatever format, we can do something at the end

7.3. Proposal to create a suite per major section of the spec

See github issue did-test-suite#50.

Markus Sabadello: relatively simple
… internal restructuring to organise the test suite into multiple suites which each contain tests related to one section
… in the initial draft of the test suite we had one suite which contained a huge list of tests
… this is a way of dividing and structuring the test suite a bit better
… will result in better reports

Daniel Burnett: also editorial

7.4. Proposal to refactor the input json into js files

See github issue did-test-suite#49.

Markus Sabadello: next is similar, about restructuring the input files
… in an early version there was a single gigantic input file with lots of dids and did docs
… and production and consumption inputs and outputs for multiple dids and did methods
… in a single file
… this issue is about organising that better and splitting up that one file
… which will be easier for people to submit their own data
… uncontroversial

7.5. Producer tests should be of the ADM not resolution result

See github issue did-test-suite#48.

Markus Sabadello: next is substantive
… other issues related
… how to properly test the ADM and different representations
… a topic that has taken time on the working calls to specify that in did core
… now we’re working on how to properly test that in the test suite
… there are existing tests that have been merged related to production and consumption and this issue is to keep track of improvements that may have to be made onto those tests
… to distinguish between the did doc as a data model and the did doc as a concrete representation
… ideally the test suite would distinguish between the ADM and the representations in clean way
… production tests and consumption tests and resolution tests would either operation on the data model or the representations depending on what the spec says

Daniel Burnett: manu’s last comment was that you, orie and cel need to get to gather to decide on a plan
… do you have a plan?

Markus Sabadello: I don’t think we have that yet
… special topic call might be an opportunity
… a case where things have moved very fast in past weeks, people have worked in parallel and done certain things slightly differently
… I think cel has done it really nicely
… very clean distinction between those layers

Jonathan Holt: one thing i was working on before was representing the ADM in ABNF rules
… that is supported in the CDDL
… I haven’t seen the test suite in a while, getting back up to speed
… but curious if I were to write an ABNF rule for the entire spec would that be received well?
… would it be a solution? I have a hard time with the ADM being too abstract, I can’t test for it
… I haven’t followed the typescript representation orie has been working on

Markus Sabadello: i suspect people would ask how an ABNF applies to an abstract data model
… probably a deeper conversation
… ABNF is a way of specifying a syntax
… specify an ABNF for one of the representations, not sure how you’d use it to describe the ADM
… but maybe I’m missing something

Daniel Burnett: probably a good topic for Thursday
… we’re missing some people today
… would be good to raise on Thursday or to submit as an issue

Markus Sabadello: point of the test suite is to test all the normative statements in the did core spec
… we need to prove that it is possible to implement all those statements
… if that can be done with an ABNF maybe that would be useful but we should look at how exactly that would be done and which statements in the spec that would test

7.6. Use of better jest matchers

See github issue did-test-suite#36.

Markus Sabadello: next is about using jest matchers
… I’m not a javascript expert so I probably can’t explain that well
… shigeya is here, maybe..?

Shigeya Suzuki: a way to define matches which is construct like a ?? sometimes useful whether you want to test whether the expected variable is in a string
… or certain kind of string
… eg. we have tons of the did identifier syntax
… so we are going to have a string that matches.. can be easier to do it.. easy to change the syntax if we want to change it
… I’m going to write matchers
… maybe later this week or early next week
… so we can refactor the entire test suite to be simpler
… that’s the idea

Markus Sabadello: sounds fantastic
… has exactly to do with this kind of parallel implementation and code duplication we have right now
… at least three different people who have worked on tests for different sections have all writen some kind of test code that checks if a string is a valid did that conforms with the syntax because that’s something that occurs in many parts of the spec
… therefore different people have implemented a test for did syntax in different ways
… if we had a jest matcher for the test suite that does that it will save everybody work
… and result in a more correct test suite
… next two are self explanatory

7.7. need clear instructions for implementers

See github issue did-test-suite#33, did-test-suite#32.

Markus Sabadello: also related to refactoring
… implementers of a did method or the spec in another way so they know how exactly they submit their data

Daniel Burnett: pretty straightforward

Markus Sabadello: last two are about sections of the spec which are still missing
… there are not tests yet

7.8. Need tests for CBOR/JSON Production and Consumption

See github issue did-test-suite#28, did-test-suite#26.

Markus Sabadello: those are about sections that don’t have tests
… 28 is about cbor
… 26 is about json
… there are test for jsonld production and consumption
… and for generic sections about production and consumption that are not representation specific
… it looks like there are no tests yet for cbor and json production and consumption
… the cbor one is assigned to Orie and json is assigned to Daniel

Daniel Burnett: we were hoping for someone like Jonathan to contribute on the cbor

Jonathan Holt: doing my best to get back in the swing with DID contributions

Daniel Burnett: daniel can you contribute on the json? the json format in particular was one of the biggest requests from Microsoft on day one of the working group
… so we really want to make sure it’s complete

Daniel Buchner: the way we’ve gone about it I don’t know… it’s worked perfectly fine working jsonld as json and saying you don’t have to resolve contexts
… I can work on any tests that take that approach
… that’s what we’re doing in our implementation
… make sense?
… are there bugs or issues out there that want it to be different than that?

Markus Sabadello: i know some people want to treat jsonld and json as equivalent and to include @context in both and this has to do with long discussions we had
… my personal opinion is this is not what the did core spec describes right now
… it does not envision that json and jsonld are byte to byte equivalent
… if that’s what WG members want to do we should change the did core spec
… right now on the test suite we need to take the normative statements
… the open issues on the test suite they list the normative statements that need to be tested
… so we need to work based on that

Justin Richer: +1 to what markus was saying
… one of the things that got brought up a necessary test condition is that a did doc that is described to be in plain json should be allowed to have the @context field and have it be a completely invalid value, and that should pass
… that should get parsed, the @context dumped into the bucket
… with whatever value it is
… no checking if it’s an array or string or anything

Daniel Buchner: Yes Justin, yeeeessss

Daniel Buchner: Love everything you are saying right now

Justin Richer: so if you have the @context value with boolean false an d a plain json encoding by the way the did core spec is defined today that is allowable
… because the re-serialization on the producer side needs to be able to place the appropriate context value and not just pass through blindly whatever it was handed
… I will say I’m not personally familiar with the structure and function of the test suite code to suggest how to contribute this piece and don’t have the bandwidth, I apologise for that
… but that is the type of corner case we need to have tests cases for
… if you’re doing lazy validation that’s not proving you’re compliant

Daniel Buchner: the interesting thing.. it doesn’t say anything about must exclude properties… isn’t lazy validation accurate?
… if you had context with a bool and the spec doesn’t say it has to be right isn’t the way i’d write the test to not deal with that property?
… lazy validation is the valid way to do it?

Justin Richer: you need to go one step further because the spec says what to say with unknown properties
… in this case @context would be an unknown property
… you need to make sure things will accept things with an invalid @context
… that’s important
… not enough to just say if i give you something an call it plain json but it’s really jsonld that you’ll be happy with that, that’s not enough
… we need to test these kinds of things
… if you do that by ignoring it using a precise definition of ignore that’s in the spec, that’s fine
… that’s not lazy validation
… that’s explicitly handling unknown properties in a particular way

Daniel Buchner: instead of completely avoiding it or not putting any lines of code that deal with unknown properties, it’ll iterate all the properties and have some sort of if that says if you’re not in the set.. log it.. do something.. recognise it exists.. if it is in the set do what you’re supposed to do?

Justin Richer: to be specific what it does is processes the serliazed property based on the type value of the serialized property and puts it into the properties map
… there will be an @context with boolean value of false inside the ADM

Daniel Buchner: ok, this makes sense

Daniel Buchner: thank you justin

Justin Richer: when it comes time to do a production from that ADM if you want to do it into jsonld your jsonld producer needs to be able to make sense of that bad @context value
… and either throw an error there or replace it with a good @context value on thew ay out which is more likely
… there are specific rules of how to handle these
… from a code standpoint it does look like the else at the end of your validators

Daniel Buchner: that’s a good answer, thank you

Daniel Burnett: issue 26 about json… Orie had asked in feb whether you might be able to contribute in writing some tests
… largely this is in here because Microsoft fought hard for it
… we want to make sure everyone else is not doing all of the test work

Daniel Buchner: I’ll try to do something about it

Daniel Burnett: I think that’s it for the test issues

8. DID core issues

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

Daniel Burnett: I wanted to ask Drummond to cover these, but he isn’t present now

Daniel Burnett: The link I dropped is about least recently updated.. Last updated was 6 days ago, which is a good sign.
… I will go through them and skip editorial ones

8.1. Explain verification suite definition and explain reuse of verification method type/material

See github issue #712.

Daniel Burnett: Any comments about this issue?

8.2. equivalentId and canonicalId should be optional

See github issue #717.

See github pull request #720.

Daniel Buchner: Let’s fight!

Daniel Burnett: All involved people of this issue seem to be on the call, maybe we can move this forward.

Markus Sabadello: I raised this because my reading of the spec text regarding the equivalent id and canonical id was that it felt like those are mandatory
… or the spec did not say that they are optional
… which is different from how other did doc metadata are described
… I raised a simple PR that adds language to say that they are optional
… I think that had support. Daniel then explained what this meant
… and what did methods have to do
… I’m not sure if the PR is sufficient or if there’s anything else that needs to bed one

Daniel Buchner: the interesting thing here is properties are required for methods that implement them. it’s a directive that says if you’re going to implement then you can’t sometimes not throw them in
… I don’t know if we reflect that in the spec test.. optional in the general sense of did docs
… if you choose to use these features it becomes required
… not sure if we should put that in

Ted Thibodeau Jr.: I’m fine with the text as its’ in 720
… it sounds like there’s an additional piece
… someplace else we said methods can be more stringent or can require something or can define things.. maybe there’s another few words to throw in
… I don’t think this would count as a normative change to push another CR
… the ambiguous test that suggested it was required would have meant that they forced it and the change to make it optional doesn’t break anything

Daniel Buchner: I can say that any method implementing these, the 4 or 5 today, would not be broken by changing it to optional in the general document sense

Ivan Herman: daniel answered for those he knows about. Any change like that does it affect existing implementations?
… if the answer is no then we are in a good place

Daniel Buchner: the answer is no
… if they didn’t, if they were broken by this change it means they were misreading the rest of the properties

Daniel Burnett: is there anything not said by the existing text after 720 is applied? take a look at 720 and if it’s not complete make a suggestion or a new PR
… thanks everyone

Daniel Buchner: will do

Daniel Buchner: gtg, thank you for all your help (Justin, Dan, Markus, Ted, etc.)