DID WG Topical Call on the Proposed Appendices on DID Identification Architecture — Minutes

Date: 2020-08-13

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Brent Zundel, Michael Jones, Manu Sporny, Dave Longley, Adrian Gropper, Markus Sabadello, Orie Steele, oliver terbu, Drummond Reed, Daniel Burnett, Justin Richer

Regrets:

Guests:

Chair: Daniel Burnett

Scribe(s): Brent Zundel

Content:

Ivan Herman: Issue to look at: https://github.com/w3c/did-core/issues/373

Michael Jones: https://en.wikipedia.org/wiki/HTTPRange-14

Ivan Herman: Google doc for the appendices: Appendix A, Appendix B, Appendix C

Ivan Herman: Cool URIs for the Semantic Web

Drummond Reed: We want to avoid http range-14 rabbithole
… but we do need to get concrete about how did documents works, and that forces us to address soe of these topics
… some context about the evolution here. You can read about range-14 on wikipedia. W3C architecture board published a document about this about 13 years ago.
… quotes from beginning of the appendix
… a URI cannot identify both a resource (such as a web page) and a person
… information resources vs non-information resources.

Michael Jones: All we really need are i-names and XRI

Drummond Reed: DIDs and DID Documents - we want to use them to identify both information and non-information resources.
… we ran into this same issue doing our XDI work. Markus and I have been discussing what we can do about this and haven’t seen any obvious answers.
… so we drafted an appendix to the spec to propose some guidance around this topic for DIDs
… There is a lot to this issue. Not sure how to structure the discussion

Orie Steele: I think this is really critical work, and it belongs in an appendix. It is valuable and strikes at a problem that is very interesting to me.
… is it the case that we can punt on this issue? What if there is only a JSON-LD version of DID Documents. Is it possible to avoid trying to solve this problem altogether?
… and what is the concrete proposal for a solution if we do want to solve it?

Drummond Reed: so we can talk about punting or solving.
… there are three possibilities for a solution, but also there is the option of not addressing this at all.

Orie Steele: sounds like punting is not a solution… one path down :)

Drummond Reed: my concern about punting is that if we do it will be hard to provide guidance around certain properties of DIDs

Manu Sporny: This is really great work. I can tell a tremendous amount of energy has gone into this. The first 4 problems are a great description of the problem space.
… I am concerned about the interpretation after page 4. I think the paper interprets things consistently, but it assumes the TAG finding is still true.
… there are new things that might make that TAG interpretation wrong.

Daniel Burnett: Or might make it insufficient, in the way that Newtonian physics is useful but incomplete?

Manu Sporny: a lot has happened in 12 years, with RDF data sets and an RDF WG.

Orie Steele: msporny can you provide any links / evidence that the TAG finding is wrong? I would love to review the other side.

Manu Sporny: there is a significant subset of people that aren’t doing what the TAG suggested.
… if we want to move this document through, it will be a lot of work.
… and if we put this in the DID spec, it will show the world the worst possible thing.
… it is asking for a long drawn out argument.
… maybe the TAG will revisit this at some point.
… I suggest we make this a note, not an appendix. That way it can be one possible interpretation, not THE WG interpretation that we need to come to consensus on.
… we’re talking about a multi-year process.
… Great work, note not appendix, but it will take us away from other work

Markus Sabadello: wanted to mention this is a topic that has come up often on the DID Resoltuion calls. there is another document linked in this issue.
… one way to address this is to say it isn’t really a problem. If we punt on it, maybe it won’t have large consequences. But it does come up aain and again.
… so if we don’t do anything about this, we have to admit some inconsistencies in our technology.
… inconsistent with web and semantic web principles. that is why we’re trying to figure out a perspective on it.

Ivan Herman: we have to be a little careful about the http range-14, because we are not in http land

Drummond Reed: I do strongly agree with Ivan that DID architecture should not be limited to “HTTP land”.

Ivan Herman: the solutions there may not be solutions for us. Things that are true for http may not be true for us.
… the problem we have is that we have conflated two different notions, the DID and the DID URL.
… that is really our problem, an abstract identifier for things, then use essentially the same syntax for something that is fundamentally different.
… semantically and syntactically these things should be different from each other and then this problem goes away.

Orie Steele: ivan can you link to your proposal?

Ivan Herman: Orie: https://github.com/w3c/did-core/issues/373#issuecomment-673376848

Drummond Reed: I am very interested in exploring Ivan’s suggestion

Ivan Herman: but it may be too late for that.

Adrian Gropper: I feel like Rip Van Winkle. I never realized there was this issue about range 14. Can someone mention one DID use case where this is likely to cause a problem?
… then if there is a use case, maybe that’s all we need to say. I haven’t run into this problem before.

Orie Steele: agropper did:example:123 => did document, person, picture of a person… ?

Manu Sporny: question for Drummond and Markus. Would you like large swaths of this to survive into the DID Core spec?
… for example, the diagrams are great, the names on the arrows are problematic.
… but they could be really helpful in describing the difference between a DID subject and a DID controller.
… I want to know what use case we cannot solve if we don’t address this now.
… Ivan is right, this isn’t entirely http range-14, but there are information and non-information resources.
… what is the use case that is convincing enough for us to work on this.

Drummond Reed: one of the challenges with this whole area is that we can practically ignore it.
… that’s why one option is to punt.
… where it came up for me that made be really want to write this up and try to find a satisfactory solution.
… I’m going to share screen and point out some things.
… we had a request to answer things about multiple DID controllers, such as in appendix D
… but what I found was that in order to answer questions like that, like when is the subject not the controller. all of these begged the question that is answered in the first appendix
… appendix A, the reason I found to write it up is that we have a PR for the representation property and a discussion around how it should work.
… this analysis has suggested there is a different property we need depending on whether it is an information or a non-information resource.
… if what you’re identifying is not an information resource, you need another property like ‘see_other’

Adrian Gropper: Is this a use-case we need: https://github.com/w3c/did-core/issues/373#issuecomment-672427360

Drummond Reed: my concern about punting is what do we do about these properties?
… the rationale about how they work would be missing without these appendices
… the could also be a note.
… the approach taken in the document. three solutions: a DID always identifies a DID Document. which functionally identifies a DID Subject.
… others pointed out, no a DID identifies a DID Subject.
… so I wrote it up again where the DID always identifies a DID Subject, which is always a non-information resource.

Manu Sporny: I like the 2nd interpretation better

Drummond Reed: you can make the whole thing work in either direction.

Manu Sporny: (although, even that has issues) :) – DID can refer to information AND non-information resources.

Orie Steele: I also like the second one better

Drummond Reed: what ivan proposed is a third option, which is to have two different identifiers.

Dave Longley: +1 to the 2nd interpretation over the first

Drummond Reed: all three represent potential solutions we could take

Manu Sporny: -1 to two different identifiers

Markus Sabadello: I’m curious, based on these documents and the issue thread and the use cases, one piece of feedback is whether we think the subject and the DID Document should have different identifiers.

Daniel Burnett: I also prefer the second interpretation as a starting point (but haven’t reviewed in detail)

Dave Longley: a DID Document is an ephemeral output/artifact of the DID resolution process

Markus Sabadello: or do we think that is not necessary? sometimes using the same identifier for both the subject and the did document, or does the did document need no identifier at all?

Daniel Burnett: +1 dlongley

Orie Steele: Citation for TAG finding?

Manu Sporny: Orie, this is one of them – https://www.w3.org/TR/cooluris/

Manu Sporny: Orie, also this – https://www.w3.org/2001/tag/group/track/issues/14

Ivan Herman: manu, not exactly; the cooluris is an Interest Group Note, not done by the TAG

Manu Sporny: ivan true – but people keep referring to it and it’s an important note…

Manu Sporny: There are four options: the fourth is to point out that the TAG finding is incorrect as of today, which was before the semantic web had a bunch of islands, which is why there was a distinctions between information and non-information

Daniel Burnett: The return of a DID document is the result of executing the default dereferencing behavior for a DID URI. It is not a resource itself pointed to by anything.

Manu Sporny: RDF changes the TAG finding. it is possible at the semantic level for the same identifier to identify two different things.
… for example Einstein - we could use it to talk about the actual person, or as a description for a generally smart person.
… the reason it works is that we now have the ability to add context to an identifier. that is why this isn’t as big a deal
… the fourth option is to do it that way.
… if we want to throw that out, I prefer option 2.
… what I’d like to do as a group is focus on the new terms we are using and focus on concrete discussion around terms.

Adrian Gropper: Again, what is the use case?
… in two different issue comments: for example, what ivan suggested, could there just be a label.
… the use case where I need a non-repudiable signature, A DID for an actual person vs a voluntary DID that can be for anything. Does that use case apply in this context?

Drummond Reed: I don’t think, as I understand it, I read your comment and that goes into appenidx c, multiple controllers bring up the possibility you bring up. but I don’t think it applies directly to this.
… it is important, but it feels like a separate issue.
… one use case that is driving this is the representation property and how it is used. there are a number of cases where we want to use a DID to identify a schema.

Manu Sporny: Orie, part of the problem is that there is no “one place” or “one finding”… it’s a series of conversations that span 15 years. :)

Drummond Reed: that schema could be in or external to the DID document.

Adrian Gropper: that feels too abstract for me

Drummond Reed: how do we identify a schema with a DID?

Manu Sporny: let’s specifically talk about representation.
… i suggest we don’t need representation.
… ledgers are doing fine using DIds to identify both information and non-information resources.
… on Veres one we have information resources that are identified with DIDs
… so I’m not sure we need representation at all

Orie Steele: manu how do you distinguish between did documents and other things on your ledger?

Manu Sporny: Orie, by type

Manu Sporny: “type”: “BunchOfBits”

Manu Sporny: “type”: “Person”

Orie Steele: this is the same issue that dbuc is addressing with type on sidetree

Manu Sporny: “type”: “Picture”

Manu Sporny: No, the solution in Veres One is general, no changes needed.

Orie Steele: does type:DIDDocument work?

Manu Sporny: yep

Manu Sporny: that’s the argument for not needing to do something.

Drummond Reed: if we want a DID to identify and be able to resolve and dereference to the representation, we need a way to do that that isn’t method specific.
… if there’s a way that veres one is doing this that could be used by all DID methods, then that’s great.

Manu Sporny: yes, it is method independent, it doesn’t require us to change anything in the spec.
… use the type property to indicate what the resource is.
… I’d be interested to hear why type doesn’t solve the problem

Orie Steele: selfissued related ION issue: https://github.com/decentralized-identity/ion/issues/77

Dave Longley: it addresses the problem as long as you can represent the resource as JSON or JSON-LD

Manu Sporny: let’s say your thing is an image. schema.org has an image property, or it could be a creative work.
… i understand the desire to have a general solution. I want us to make sure we are considering a specific use case.
… representation is a general solution.
… when we’re talking about this stuff, maybe this stuff shouldn’t be in DId land, maybe a VC is better for this.
… I assert this is the wrong thing to do.

Orie Steele: Seems to me that JSON-LD has a solution for this, and we would probably not invite these general uses of it for other things in DID Core… and yes, agree this kind of information does not really belong in the did document… seems like conflating DPKI with assertions about resources

Drummond Reed: I’m glad we are on this, which is the problem that led us here. It isn’t clear what the relationship is between the DID and the representation.
… the big aha for me was, the DID Subject IS the schema. there is no relationship between the DID and the schema, the schema is the Subject and you can use the dereferencing of the DId Document to get it.
… maybe we need to figure out the semantics of these properties.
… representation by value is the case that I’m convinced has enormous value.

Orie Steele: yep, i would prefer to use type, and support by reference as well…. and flatten away “representations” object.

Daniel Burnett: You don’t dereference a DID document. You dereference a DID URI to get a DID document or the fragment of a DID URI to get a service endpoint

Markus Sabadello: ia want to bring up another thing. we might want different identifiers for DId Subject vs DId Document.

Manu Sporny: +1 to what Orie said above – “I would prefer to use type, and support by reference as well…. and flatten away “representations” object.”

Ivan Herman: +1 to markus

Markus Sabadello: metadata will have concrete data formats, it is data about the DID Document. That means the DID Document needs a separate identifier.
… otheriwse we can’t refer to it.

Manu Sporny: the use case is absolutely valid. we need to find a way to represent these things. There is an assertion that we can already do this.
… there is a lot of good stuff in the documents you’ve written.

Daniel Burnett: +1 Markus, a DID document is returned by the dereference of a DID URI, but that does not mean it is the resource identified by the DID URI.

Manu Sporny: let’s figure out what we should pull into the DID spec, what should be a note, and then continue a conversation around representation, with some concrete leaf use cases.

Adrian Gropper: I prefer the second version of the diagrams

Drummond Reed: I think that’s a good way forward. I will also share a PDF of the alternate version. let’s drive forward on the discussion of that.

Daniel Burnett: Maybe it’s worth thinking about the difference between a DID Document as a file with an HTTP URI and a DID Document that is returned as the default dereference of a DID URI. They are not the same.

Drummond Reed: also Markus and Ivan’s points about needing two different identifiers is also worth exploring.

Manu Sporny: +1 good conversation!

Orie Steele: excellent conversation, very helpful

Daniel Burnett: this was a good conversation. thanks everyone.

Orie Steele: yes, thank you for the work… very helpful