DID Extra F2F preparation call — Minutes
Date: 2020-01-17
See also the Agenda and the IRC Log
Attendees
Present: Ivan Herman, Rob Sanderson, Manu Sporny, Amy Guy, Orie Steele, Markus Sabadello, Justin Richer, Dave Longley, Brent Zundel, Oliver Terbu, Kenneth Ebert, Tobias Looker, Michael Lodder, Daniel Buchner, Samuel Smith, Benjamin Young
Regrets:
Guests:
Chair: Brent Zundel
Scribe(s): Amy Guy, Manu Sporny
Content:
Brent Zundel: Today’s primary topic is agreeing on where we disagree
… Any additional questions that we feel need to be answered?
… Anything else people want this meeting to be used for?
… manu got a document out
Manu Sporny: the email sent out to the list is here..
Manu Sporny: Manu’s list of concerns, disagreements, questions – https://lists.w3.org/Archives/Public/public-did-wg/2020Jan/0013.html
Manu Sporny: I’ve had some one on one conversations and tried to read through all of the PRs and issues and consolidate it into root cause disagreements, issues and concerns
… not complete by any means, just documenting what I can see
… I think we’re picking up with disagreements this time
… These are things we agree that there’s a disagreement on this
Manu Sporny: DISAGREEMENT: Extensibility is being prioritized above security in the current DID specification.
Manu Sporny: Somebody said something and somebody else agreed that it was a disagreement
… That we’re focussing on the wrong thing, that we shouldn’t focus on extensibility but on security, there’s disagreement on that
… The second one I’ve heard only two people raise this
… I thought it was interesting
Manu Sporny: DISAGREEMENT: IOT is the primary use case for DIDs by many orders of magnitude.
Manu Sporny: There’s disagreement about the primary use case
… There are at least two people who said VCs are nice but if you think that’s the primary driving use case for DIDs it is not
… The use case is that we’ll have billions of devices which need to be able to do activities, already working groups on that stuff
… If the DID WG messes this up you’re going to have a whole bunch of IOT devices that pick a different solution, primarily by making it over complicated by using JSON-LD
Manu Sporny: DISAGREEMENT: The IOT use case and use of JSON-LD are incompatible.
Manu Sporny: IOT is simple, compact, straightforward, low code size, really tight security parameters, and JSONLD is the opposite of that in almost every way
… There’s little to no overlap
Manu Sporny: DISAGREEMENT: Data in DID Documents are not intended to be co-mingled with data retrieved from Verifiable Credentials.
Dave Longley: notes that “JSON-LD is the opposite of that in every way” is an assertion that is contested and part of the disagreement
Manu Sporny: Folks are saying that JSON-LD is fine for VCs, because there’s all this data that needs merging and you need good semantics
… And that you don’t need that for DID Documents
… You don’t need that level of extensibility, you’re not going to be merging DID Docs with VCs
… Where it makes sense for VCs it doesn’t make sense for DID Documents, two different problem domains
… Disagreement over whether that’s true
Manu Sporny: DISAGREEMENT: JSON-LD makes the same mistakes that XML made in the late 1990s.
Manu Sporny: This one, that in the 90s people were excited about namespaces, and having globally understandable documents
… but what happened was those architectures lost because they were overly complicated, systems didn’t need it
… Therefore json-ld is trying to do the same thing that xml was but in JSON and we know how that played out
… XHTML lost to HTML5, JSON won over XML, SOA was kicked to the curb
… We don’t need to relive that failure
… I’m sure there are more. That was the hardest list to get together
… Difficult to articulate an assertion and disagreement over an assertion
… What other disagreements are there?
Brent Zundel: jump on the q if you have either a disagreement about a disagreement
… If there are additional disagreement that you want recorded and addressed, chime in
Markus Sabadello: one item of disagreement, may be part of something already mentioned, is how extensibility should work
Dave Longley: DISAGREEMENT: There is a simple way to support both JSON-LD and JSON-only expressions of DID Documents together.
Markus Sabadello: Should extensibility work through a registry process or in a decentralised permissionless way
… it’s connected to the things manu said, the namespaces and combining of data
Orie Steele: +1 (we don’t agree on how the spec should support extensibility)
Markus Sabadello: it could be a separate item
Manu Sporny: +1 to Markus’ disagreement, because it’s more precise.
Markus Sabadello: DISAGREEMENT: How extensibility should work
Markus Sabadello: DISAGREEMENT: How will extensibility of DID documents work? E.g. registry process, or decentralized permissionless, process, etc.
Tobias Looker: one of the disagreements I saw that stood out, related to markus, how extensibility would work using JSON-LD and the implications for JSON developers, and how the implications are on the level of understanding needed by someone who is unaware of JSON-LD
… what are the requirements that would preserve JSON-LD like functionality for non-JSON-LD developers
Justin Richer: The disagreement I’ve seen throughout the issues, is what the burden will be on different classes of developer.
Orie Steele: DISAGREEMENT: There should be a way to detect if JSON-LD is meant to be used or not.
Justin Richer: So, requirement or removal of @context, led to a lot of discussion about how much harder or easier it would make, depending on which camp you’re in. There seem to be a lot of disagreement about what group of developers this group is trying to make things easier for.
Dave Longley: I typed my disagreement above as well, there is a disagreement that there is a simple way to support both JSON-LD and JSON documents together. This has to do with who is going to bear what burden.
Justin Richer: DISAGREEMENT: What is the burden on developers for either inclusion or removal of JSONLD components for either JSONLD or JSON devs?
Justin Richer: +1 to dlongley
Dave Longley: DISAGREEMENT: There needs to be a way to distinguish between JSON-LD and JSON DID Documents.
Daniel Buchner: There is one implicit disagreement, which is who are we targetting - I hope there is an emperical argument… from my standpoint, target most number of developers in easiest way.
Tobias Looker: DISAGREEMENT: How extensibility would work in a JSON-LD enabled DID Document and the implications for developers who are un-familiar with JSON-LD
Justin Richer: +1 to that statement, this is corollary to what I was saying
Daniel Buchner: Are we targeting the broadest set of people in easiest fashion, or not - we could have a discussion around that.
Brent Zundel: DISAGREEMENT: who are we targeting as users of the spec
Daniel Buchner: Is the spec targeting the broadest group of developers possible with the easiest integration, or is that not a primary goal?
Samuel Smith: Universality with finite extensibility is more valuable than ultimate extensibility without universality
Orie Steele: I might as well verbalize my #1 disagreement, we are agreeing to this disagreement, there is no way to detect the feature of JSON-LD today. We all agree that it’s impossible to intend to support it in the current spec. I would like to see a resolution to that.
Amy Guy: ^
Orie Steele: Independent of whether or not JSON-LD is used in the DID spec, I’d like to know whether or not it was intended to be used in the DID Method spec.
Amy Guy: is there a disagreement that we even need extensibility at all? has anyone proposed just not having extensibility and keeping it fixed data model [for this version]?
Samuel Smith: Best way to detect intent to use JSON-LD is the presence of @context
Michael Lodder: limited extensibility is a requirement
Amy Guy: yes, that
Amy Guy: no more additional properties
Daniel Buchner: Do you mean we can’t add more properties, or fixed as it can never change?
Brent Zundel: No more additional properties?
Amy Guy: [for this version]
Samuel Smith: Limited extensibility can be a process for adding properties
Amy Guy: yeah I’m handwaving versioning a bit
Daniel Buchner: Ever? Or v1, then v2, etc.
Brent Zundel: This version would be fixed, if you want more properties, it would be in a future version.
Dave Longley: DISAGREEMENT: The best way to detect intent to use JSON-LD is the presence of
@contextas opposed to the presence of additional contexts beyond the core context.
disclaimer: I have only skimmed the threads
Oliver Terbu: I think there is disagreement on who decides which data model or encoding will be used - is it resolver, DID Method spec, DID author, etc.
Oliver Terbu: DISAGREEMENT: I think there is disagreement on who decides which data model or encoding will be used for the DID Document, e.g., resolver, DID method spec author, etc.?
Brent Zundel: Does anyone disagree w/ the list of these disagreements?
Samuel Smith: Disagreement: with Disagreement the presence of @context is way to message intent to use JSON-LD
Orie Steele: DISAGREEMENT: We have not established who defines did core spec compliance for a did method. (document author, method spec author, resolver) (duplicate of oliver’s)
Brent Zundel: These will factor into the Chairs planning of the F2F meeting.
Markus Sabadello: There may be disagreement about whether or not a DID Document is a resource on the Web, or is it more like a DNS record, lower layer that’s not on t he Web? Sometimes we treat it like it is, sometimes we treat it another way.
Ivan Herman: +1 to markus_sabadello
Dave Longley: Response to Markus, it might also be the case that DID Documents may play both roles depending on DID Method.
Orie Steele: sounds like a duplicate of “who defines did core spec compliance for a did method”
Samuel Smith: Establishment of control authority or not in a DID Doc is a vital
Markus Sabadello: DISAGREEMENT: Is a DID document a resource on the web with a URL that can be dereferenced, or is it more like a DNS record that exists not on the web but on a lower layer. Or can it be both, and if it can be both, then what does it depend on?
Dave Longley: There seems to be a concern around primary purpose of DID Document. Keys, services… or if it’s somehow used to get to the authoritative information about a DID Subject.
… There is confusion around “getting to” vs. “what is in” a DID Document.
Orie Steele: DISAGREEMENT: we don’t have the separation of control authority from the semantics of a did subject defined
Orie Steele: ^my attempt at dave
Dave Longley: DISAGREEMENT: The primary purpose of a DID Document is to provide information about a DID subject (such as services to interact with them and what keys they have authorized for what purposes) vs. establishing authority over the DID.
Samuel Smith: My concern is that, per my presentation last DID meeting, we have two tasks in front of us as establishing a DID as the authority over a DID. There is confusion among whether or not the DID Document plays an essential role or an optional role.
Dave Longley: DISAGREEMENT: DID resolution is about establishing an authoritative DID Document for a DID and DID Documents must necessarily express something else after that.
Samuel Smith: If DID Documents are optional, then the DID spec itself has a huge hole in indicating how we establish authority. If we say all methods get to decide how to do that, then we have to say that DID Documents don’t establish control authority.
… If we say that DID Doc does play a role, but we have multiple ways of establish control authority that will be a mess. It’s more important than some of the things we’re talking about.
… The disagreement is that we don’t know what we’re doing.
… We’ve said it’s up to the method, and whether the method uses the DID Document or not is up to the method.
Orie Steele: this sounds like a combination of markus’ comment and dave’s.
Samuel Smith: Is this a lower layer? Role of a Dynamic DNS server, or is it a higher layer, once you’ve resolved the IP address, and authenticated, now you have an authorized piece of information that you can end-verify to the control authority and you know it’s a valid DID Document.
Dave Longley: DISAGREEMENT: A DID Document expresses information about a DID subject that may or may not self-contain a way to check the authority of that DID Document for that DID.
Samuel Smith: As far as I know, we’ve punted to the Methods on that question.
Markus Sabadello: To what Sam said, maybe the disagreement is whether that’s a bug or a feature.
Dave Longley: I was trying to capture that… A DID Document expresses information about a DID subject that may or may not self-contain a way to check the authority of that DID Document for that DID… so, it might be that some DID Documents can self-contain that information, and others don’t, and that might depend on the DID Method.
Dave Longley: DISAGREEMENT: A DID Document expresses information about a DID subject that may or may not self-contain a way to check the authority of that DID Document for that DID (it may depend on the DID method).
1. Open Questions
Brent Zundel: What are the open questions, we have some from Manu.
Manu Sporny: back to the email..
Manu Sporny: Manu’s list of questions - https://lists.w3.org/Archives/Public/public-did-wg/2020Jan/0013.html
Manu Sporny: They’re intended to attempt to ask the right questions so we get answers to the concerns and disagreements
… we could maybe ask that would illuminate some part of the discussions
Manu Sporny: QUESTION: What is the technical use case that is made not possible due to the use of JSON-LD?
Manu Sporny: What use case can’t you do because you are using json-ld? It could be ‘make it as simple as possible’
… What specific technical use case
Manu Sporny: QUESTION: What are the specific technical implementation burdens that are created by the use of JSON-LD?
Manu Sporny: What specific, these lines of code and that is unacceptable
… or I have to go out to the network and that is unacceptable
… Those types of answers
Manu Sporny: QUESTION: What are the specific costs of using JSON-LD DID Documents?
Manu Sporny: eg. I’m a JSON only developer and here are the very specific costs to my implementation or ecosystem because that document is JSON-LD
Manu Sporny: QUESTION: What is the definition of “JSON-LD Processing”?
Manu Sporny: There have been a number of people who have either asserted you don’t have to do any json-ld processing, or of course I have to, jsut you saying I don’t have to doesn’t mean
… Getting the definition of what people mean by JSON-LD processing might be helpful, because it might be that people have different definitions, one is colloquial and one is from the JSON-LD spec
Manu Sporny: QUESTION: What is the extensibility model for JSON-only DID Documents?
Manu Sporny: We know what extensibility for JSON-LD DID DOcs is
… W’ev seen people suggest mechanisms for JSON only documents but we should get them on the table, we need some understanding about the options
Manu Sporny: QUESTION: Do people understand that JSON-LD is a more restrictive subset of JSON, so JSON-LD is JSON and is designed to be a “Chimera document format”?
Dave Longley: and what are the properties of the extensibility model? (e.g., does it create globally unambiguous semantics?)
Manu Sporny: When people are saying JSON-LD isn’t JSON, from a technical standpoint it is, but that’s probably not the point of contention
… Are people familiar with Chimera document formats?
… Having a discussion around what are Chimera document formats and when to use them might be helpful
Manu Sporny: QUESTION: Does everyone understand that you do not need to go out to the network to process a JSON-LD document and that verifiers SHOULD NOT go out to the network to retrieve JSON-LD Context documents?
Manu Sporny: The last question had to do with a discussion we had on the list
… Having a discussion around that might be helpful for folks who are concerned about security implications or what happens if the document changes
… Those are some of the questions that might help us have discussions
Justin Richer: QUESTION: Can JSON LD processors work with an implied
@contextfield?
Orie Steele: I think what I wanted to ask might be covered by Manu’s questions. When we are talking about abstract data models, are we talking about graphs or trees?
… At the core, this is really Linked Data or not Linked Data, and that conversation is graph or not graph. Might be helpful to review graph vs. not graph data structures, why you would use one over the other.
Justin Richer: +1 to ken
Justin Richer: (and that gets at my question too)
Kenneth Ebert: I wanted to look at the converse - if we adopt a JSON-only data model, what are the implications to the JSON-LD community? Are there things that are difficult to do, impossible to do? What happens if we use JSON-only?
Dave Longley: QUESTION: If a JSON-only model is used, what kind of interoperability problems does it create (or could it create without careful work)?
Markus Sabadello: One open question is - if you’re in one of the two camps and you have a preference for one of the data formats, what will your software do when you see the other one?
Kenneth Ebert: QUESTION: If a JSON-only model is adopted, what are the things that are impossible or difficult to do as a JSON-LD developer?
Markus Sabadello: One way of answering that is it’s the resolver… but another is that DID Methods may only support one.
Dave Longley: QUESTION: Can libraries be easily written such that they don’t have to care about the DID method, only the DID Document?
Justin Richer: activitystreams 2.0 did that with an option to infer the context from a new MIME type, and I think in the end nobody liked that solution and I don’t know if any JSON-LD libraries/processors or any generic tooling has implemented it at all
… All I asked was, could JSON-LD processors work with an implied context field? That gets at the question Ken was asking, if there was JSON-only, what are the costs to the JSON-LD community - can JSON-LD work in that space? That’s a more fundamental question, I had a specific instancfe of that question.
Dave Longley: I put my question into IRC - can libraries be easily created that can generically process DID Documents?
Markus Sabadello: QUESTION: If you have a preference for a certain DID document format (e.g. JSON or JSON-LD), what will your software do if it encounters the other format that you don’t prefer?
Justin Richer: Not to add a question, waiting for queue to empty - I think that we as a community really do need to come down on the side of this beign a JSON-LD document or always processable w/ just JSON tools and literally nothing else, no schemas, no nothing, because what we have right now is not serving either community well… because it’s doing things that are not quite true.
Oliver Terbu: QUESTION: Does the JSON-LD extensibility model prevent interoperability if security should not be compromised?
Justin Richer: I don’t have a strong opinion on what side we land on, but I strongly think that we do need to pick one.
Kenneth Ebert: +1 to Oliver’s concern
Dave Longley: +1 we should absolutely enable processing with just things like JSON.parse() and
===, even if JSON-LD is used.
Justin Richer: dlongley: yes that’s what I was going for
Justin Richer: +1 to markus_sabadello, the quesiton is important
Markus Sabadello: Not sure if it’s a question or disagreement, Do we want to pick one, or do we want the ability for others to come up with more formats, like CBOR or IPLD? Do we want to include that in our thinking? Or do we want to absolutely pick one?
Kenneth Ebert: +1 to Markus question
Markus Sabadello: DISAGREEMENT: We have to pick 1 data format vs. we will allow more (unlimited?) data formats e.g. CBOR, IPLD, etc.
Brent Zundel: For the record, I am working on an interpretive dance format for DID Documents.
Samuel Smith: There are two aspects interoperability. One is at the encoding layer. Encoding leverages tooling for that encoding. Support for more encodings provides interoperability between encoding specific tooling. This broadens adoption. Limited extensibility between tooling ecosystems is to be expected.
Brent Zundel: So this is near and dear to my heart (and legs)
… Appreciate the input, the Chairs are going to try hard to address as many of these in the Agenda that’s created.
Samuel Smith: The other interoperability is within a tooling ecosystem. One can have higher interop and more extensibility within a tooling ecosysystem. The problem is trying to force a given tooling ecosystem on everyone. This is problematic
Rob Sanderson: A question, but not capital question, could there be a list of agreements that could contribute to the concerns/disagreements? Is there general agreement that tool-chain needs additional work? Or is that not a disagreement we’ve talked about.
Brent Zundel: I think that’s a great question - does anyone want to elucidate areas in which we agree.
Manu Sporny: a little generic, but all of us want to build the biggest possible tent
… within reason
… we want the DID spec to be used by the most number of developers
Dave Longley: AGREEMENT: We should enabling processing DID Documents using JSON only tools like
JSON.parse()and===even if DID Documents use JSON-LD.
Manu Sporny: without creating any security holes or vulnerabilities, and maximising peoples’ independence while ensuring we’re maximising interop
… I don’t think anyone would really argue, but that’s the general thing you strive for with any kind of WG
… I’d be surprised if anyones aid absolutely not, we have a narrow target
… The other thing that I think we agree on is that security is probably the number one concern
… it’s not extensibility is number one. If this thing is not secure it won’t work. Full stop. Security is number 1.
… Secondary is developer usability, and then maybe a distant third is extensibility
… There are various other things we care about as well
… I think we all agree we want to make sure this thing is absolutely secure
… I do also think we agree that we do want to .. someone might disagree… I think we agree that we don’t want to lock ourselves in to whatever we’re doing this year and next year
… we do want to think about other syntaxes like cbor, we do want to target JSON - I think we agree on that - and I’m saying that includes JSON-LD - and we do want to think about the future
… use cases like cbor and things like that
… I haven’t had a chance to look at many of the concerns and disagreements but at a fundamental basis I think people are operating in good faith and we’re trying to work through this and get something that works for everyone without raising the burden so high for any community that it’s impossible for them to use the spec, because that would be a failure because that subset will do their own thing and we’ll all suffer if we confuse the market
… I also think we agree on the notion that unbounded extensibility is a bad thing
Dave Longley: AGREEMENT: Anyone reading the spec should be able to understand the core DID Document data model (not extensions) without having to understand how to write extensions.
Manu Sporny: Extending whatever, whenever, is a bad way to interop
… I think we also agree on limiting the spec in very specific ways and saying you shouldn’t use these features of some of the technologies is an appropriate thing to do in the spec
… I think we do agree on the fundamentals, which is why I still have hope we’ll find a solution
Brent Zundel: I think we all agree that we want DIDs to be a spec that comes out of the W3C and this WG
… We’re all here because we want to produce something and we want as many people to use it as possible
… thanks azaroth for stimulating the agreements
… our next time will be on our regularly scheduled call on Tuesday; next additional call is Wednesday at the same time as this
… Thanks everyone!