DID WG Topic Call on Issue Processing Working Session — Minutes

Date: 2021-02-16

See also the Agenda and the IRC Log

Attendees

Present: Shigeya Suzuki, Brent Zundel, Ted Thibodeau Jr., Manu Sporny, Markus Sabadello, Kyle Den Hartog, Adrian Gropper, Orie Steele, Wayne Chang, Drummond Reed, David Waite

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Kyle Den Hartog, Manu Sporny

Content:

Brent Zundel: purpose of meeting is to look at PRs and find consensus on them in prep for CR
… turning things over to Queue

Manu Sporny: Sent email out with statements to help get clarity around
… looking at the PRs that have disagreement on
… going to copy paste them as we go
… one has to do with ADM
… and what it’s intended to test
… the next is about testability of resolution section and how pedantic we want to me
… third is about representation specific properties
… how are we planning to deal with these
… is there anyone on call that has a proposal that may make it easier for us to resolve them

Kyle Den Hartog: I think those are higher priority, I’d like to add on DID COntext issue – small one, want some resolution.

Manu Sporny: let’s address ADM model first because it has most prolific effect. Any objections?

  1. The ADM MUST ONLY be used to represent a DID Document.
  2. The ADM can be used to represent any data structure in the DID Core specification, e.g., a resolution metadata structure, or a verification method.

Manu Sporny: These are two statements we have that. I think these are the two fundamental section that should be discussed

Markus Sabadello: I think this is related to the second topic as well. I expressed my opinion on that previously. I don’t think we should expand past the DID Document for ADM
… I will also note that there’s been a few PRs that have already moved us in that direction. I don’t think they should have been merged
… one was editorial and I don’t think it was editorial. The second had an objection but was also merged

Manu Sporny: Anything that was merged that shouldn’t have been merged should be reverted out

Markus Sabadello: https://github.com/w3c/did-core/pull/631 and https://github.com/w3c/did-core/pull/601 added language about expanding the data model that I think shouldn’t been merged.

Manu Sporny: I haven’t seen any issues but we’re moving quickly so may have missed something
… I think theres a fundamental contention that the ADM was for only the DID Document and nothing else
… normally when a programming language has a ADM it doesn’t also place limitations on what that data model can be used for
… it’s strange to say that only the DID Document can be expressed in the ADM and I think it’s overlimiting, doesn’t buy us anything, and makes issue 2 (resolution testability) more complex

Orie Steele: I think we’ve opened the world for what a DID Document can be beyond what has been imagined
… Anything can be added to the DID Document as long as id property is present
… I think it’s incorrect to assume the additional resolution data isn’t also part of the DID Document
… it’s poor engineering if we say that unknown properties can’t be handled
… they can have anything else in it as long as the id, I think we need to agree on what a DID Document is first before we talk about ways to get them

Markus Sabadello: I think you misunderstood me Orie. I didn’t say it couldn’t be anything and be extensible. I think that’s fine. I think what you said actually supports my perspective a bit more and Manu is saying the ADM should apply to other structures that don’t have an ID
… I think it’s a good thing to keep the DID Document as is and don’t think we need to change that

Manu Sporny: to answer why do we need now question, it’s been to assist with resolution section for testing
… we want to make sure there’s a clear line for going from the ADM to something testable other than for a few INFRA maps
… it’s fairly obvious that they should be converted to JSON, but without saying that it’s not clear that’s how that should be handled
… We have these maps of did document metadata. How do we tell implementors how to handle those maps?
… we can reference the resolution sections to make it easy to serialize the maps into JSON
… if you have a map just go take a look at the JSON serialization rules. It didn’t cut off any use cases we had before, but made it clear for implementors of how to go from ADM to a representation when we have these additional maps
… if we don’t want to do that then we’re just going to end up repeating the same language
… thats the why we need this. If we don’t have that we need to find a different way to handle the testability
… I’d like to run 2 proposals to see if we can move on

Brent Zundel: add your self to q to run the proposals

Markus Sabadello: the section on metadata structure already has some examples
… I think it would be much simpler to add a sentence to reference the INFRA spec
… I think this makes it testable without expanding the scope of the ADM at this point

Orie Steele: I misinterpreted markus earlier
… the issue here is the did resolution buckets
… I agree this is a problem, one solution is to say there’s only one way to return which is JSON, another is to add the additional objects to the ADM and say how to handle that

Drummond Reed: It seems to me that resolution data is out of scope and if that’s true then should we be handling it?

Orie Steele: I think we migtht be better off kicking the meta data out of the spec, or handling in in all supported representations… its going to hurt to split the difference.

Markus Sabadello: I understand orie’s rationale that when you resolve a did then you get back the whole resolution object in JSON-ld or cbor
… I think it’s a mistake to think the whole resolution object is not a single object
… we agreed that they are separate objects and the encoding/serialization may be different
… you may get them in different ways so we should avoid the impression that they’ll always be combined
… we could use JSON as an example, but I think reusing the entire ADM goes to far and is misleading

Markus Sabadello: I think I would agree to expand the data model to parts of DID document, but not to metadata

Manu Sporny: Gonna run the proposals

Proposed resolution: The ADM MUST ONLY be used to represent a DID Document. (Manu Sporny)

Manu Sporny: wanna note that this about specific aspects in the DID Doc such as Verification Method or service object

Manu Sporny: -1

Drummond Reed: 0

Kyle Den Hartog: 0

Ted Thibodeau Jr.: -0.5

Orie Steele: +1

Markus Sabadello: +0.5 (okay with using it for parts of DID documents, but not for non-DID document structures)

Shigeya Suzuki: 0

Brent Zundel: 0

Proposed resolution: The ADM can be used to represent any data structure in the DID Core specification, e.g., a resolution metadata structure, or a verification method. (Manu Sporny)

Manu Sporny: +1

Orie Steele: +1

Drummond Reed: 0

Kyle Den Hartog: +.5

Markus Sabadello: -1

Shigeya Suzuki: +0.5

Brent Zundel: 0

Ted Thibodeau Jr.: +1

Proposed resolution: The ADM is only used to represent a DID document or parts of a DID document (e.g. a verification method) (Markus Sabadello)

Manu Sporny: -0.5 (I think this would be better, but doesn’t address the issue)

Drummond Reed: +0.5

Markus Sabadello: +1

Kyle Den Hartog: +1

Ted Thibodeau Jr.: -0.5

Drummond Reed: +1 to Kyle’s suggestion

Shigeya Suzuki: +1 to Kyle’s suggestion

Orie Steele: we should remove all normative statements associated with resolution response that are not about the did document.

Drummond Reed: +1 to Orie’s point

Manu Sporny: I would like to specify that the ADM can be specified for DID Document or sub structures. I think Kyle’s proposal is ugly but if people will support it then we’re going to have to find a way to make it work

Drummond Reed: It seems consistent with we’re only specifying the contract

Manu Sporny: My concern is that while that’s what we’re saying that’s not what the spec text is actually doing. We’re specifying something beyond abstract

Drummond Reed: I’m in favor of revising the spec text to make sure that it is consistent with keeping it at the level of a resolution contract

Markus Sabadello: In theory this would work by making this testable at least
… it’s sufficient to say that it can be done in some way without stating how to do it in greater detail

Kyle Den Hartog: +1 better not to over specify now and leave much of that for did resolution work

Drummond Reed: If there’s normative statements that demand at a lower level than what’s testable then we need change those statements
… What ever level we’re after we need to update the language to make it work

Kyle Den Hartog: +1

Brent Zundel: is there anyone who’d like to modify changes to the proposal?

Proposed resolution: The ADM is only used to represent a DID document or parts of a DID document (e.g. a verification method). For DID Resolution data structures, INFRA will be referenced normatively, as well as the JSON serialization rules for INFRA, to note that the data structure must be able to be serialized using INFRA->JSON rules. (Manu Sporny)

Orie Steele: +1

Kyle Den Hartog: +1

Drummond Reed: +1

Markus Sabadello: +1

Shigeya Suzuki: +1

Brent Zundel: +1

Manu Sporny: +0.5 (weird and duplicate text in the spec)

Ted Thibodeau Jr.: +0.5 is viable … but people are definitely gonna try to wedge apples into that bag for oranges

Resolution #1: The ADM is only used to represent a DID document or parts of a DID document (e.g. a verification method). For DID Resolution data structures, INFRA will be referenced normatively, as well as the JSON serialization rules for INFRA, to note that the data structure must be able to be serialized using INFRA->JSON rules.

Brent Zundel: Where do we go from here?

Manu Sporny: I think that resolves issue 1 and 2, my hope that the next proposal will pass
… if you -1 this proposal you’re saying even if it’s possible (it now is after last resolution) then you’re saying that you don’t want it

Brent Zundel: would it be fair to say if the caveat it’s not then should we add language to support that?

Manu Sporny: if it’s not possible we need to talk about it

Drummond Reed: if something falls under human testable category what should we do?

Manu Sporny: we should talk about it if it has to be human testable

Proposed resolution: If possible, and in order to increase interoperability, we should ensure that every normative MUST statement is machine-testable in the DID Resolution section. If it turns out to not be possible then further discussion will be necessary. (Manu Sporny)

Manu Sporny: +1

Drummond Reed: +1

Kyle Den Hartog: +1

Ted Thibodeau Jr.: +1

Orie Steele: +1

Brent Zundel: +1

Shigeya Suzuki: +1

Markus Sabadello: +1

Adrian Gropper: +1

Resolution #2: If possible, and in order to increase interoperability, we should ensure that every normative MUST statement is machine-testable in the DID Resolution section. If it turns out to not be possible then further discussion will be necessary.

Manu Sporny: next one has to do with representation specific entries
… there’s thing that are specific to representations like @context which could be argued is specific to json-ld, yaml versions for yaml, etc
… we’ve said these representation specific things have to be kept in the ADM
… this has lead to some disagreement
… for example how to go from an ADM without @context and returning JSON-LD, where does that context value come from?
… these are the 3 things we could talk about let’s go to the queue

  1. The representation-specific entries go into the DID Document data model.
  2. The representation-specific entries go into some other data model.
  3. The representation-specific entries go into the DID Document data model AND some representation- specific map.

Markus Sabadello: I’ve felt uncomfortable including representation specific properties in the ADM
… seems like a violation of layers
… could produce issues later on when new presentations are defined
… I’m not sure what the solution. Out of the 3 options listed I like option 3 best
… that with clarity around what the production rules are doing could help

Ted Thibodeau Jr.: Can we put all the core stuff into Registries, with their @context alongside as with any non-core stuff, such that the only things that would get a magic @context would be unRegistered whose authors are clearly warned that Here Be Dragons if they fail to register their special thing? So, no big @context for Core, just lots of little ones for each and every…

Drummond Reed: we’ve discussed for quite awhile. Is there a proposal that we can be specific about?
… I’m asking for clarity on that is all

Markus Sabadello: Controversial diagram: https://github.com/w3c/did-core/pull/596

Manu Sporny: let’s try option 3, but sounds like Markus wanted an OR rather than AND. Let me see if I can rework that
… let’s give this a shot
… I think this is going to be used to argue that json-ld shouldn’t include the @context property
… let’s here from Markus and Orie to see how we might handle it

Markus Sabadello: +1

Drummond Reed: We passed a resolution several calls ago to say representation specific entries must follow production rules

Orie Steele: We’ve been over this and resolved that and I’ll be -1 on going back on that. Markus and Justin have brought up a good point about what happens when you start with empty ADM. How should production handle this?
… either we add this to ADM which feels wrong, or we have a production rule which applies specifically to the representation when combined with the ADM
… those who are still wanting to work on this please discuss offline

Shigeya Suzuki: I’m wondering whether ADM is read only or not…

Brent Zundel: we’re out of time

Manu Sporny: It is not read-only.

Ted Thibodeau Jr.: also, what does production mean/require when you’ve consumed 1000s of DID documents with lots of individuated special properties? Do you have to output 100s of empty properties, or is it OK to leave out empty properties (we often say it’s not)>

Shigeya Suzuki: Then, how we can guarantee these two are in sync… is a question

David Waite: I had the benefit of watching things unfold

David Waite: and I guess of manu being so incorrect that markus was incorrect too by proxy

David Waite: (if I picked that up right)

1. Resolutions