DID Extra F2F preparation call — Minutes

Date: 2020-01-14

See also the Agenda and the IRC Log

Attendees

Present: Drummond Reed, Ivan Herman, Michael Jones, Manu Sporny, Amy Guy, Orie Steele, Brent Zundel, oliver terbu, Joe Andrieu, Kenneth Ebert, Markus Sabadello, Dave Longley, Tobias Looker, Dmitri Zagidulin, Samuel Smith, Michael Lodder, dbuc

Regrets:

Guests:

Chair:

Scribe(s): Amy Guy, Drummond Reed

Content:

Brent Zundel: The purpose of this call is to help us prepare for the f2f
… the topic is around the abstract data model, json, json-ld syntaxes, specifically what we are not wanting to talk about is resolutions and solutiosn adn proposals for those problems
… what we’d like to cover is to record and find agreement on the points of disagreement
… what topics do we need to cover and come to agreement on
… the purpose of this call is to “gather questions that need to be addressed, to agree on the things we disagree on, to gather concenrs, and other things that will drive the f2f agenda” (manu)
… manu has some proposals to get us started
… if anybody else has proposals or ideas, or wants to throw concerns out we can start recording those
… put yourselves on the q

Michael Jones: as a meta point, I’m going to have to drop off half way through the call
… the main thing I want to see if we have agreement on is that we must drop @context from the json representation
… I hope we have agreement on that because it takes us a long way
… I’ve seen a lot of support for that in the issues

Markus Sabadello: one thing I think would be get to agreement on would be when we talk about ‘encoding’, a term we use a lot, do we mean encoding in the sense that different encodings of something can be converted between each other in a way that is lossless
… eg. we talk about base58 or base64 or hex encodings, those are encodings of bytes and can be converted without losing any information
… I think we should answer the question whether that’s what we mean by encoding, if we have a json ld or json or cbor, do we want it to be the goal to always convert these encodings, or do we say it’s not a goal and we mean encoding in a way that can be converted within limits

Dave Longley: Two things, my first is a response to mike jones
… we still have significant disagreement, I think it’s a point of contention about what to do with @context
… theres’ disagreement in the group
… We might have made significant breakthrough, I don’t think Sam SMith is on this call, but we might have a pathyway for resolving some of Sams’ concerns
… when he gave a presentation earlier on the call today he talked a lot about what is essentially a lower layer from did documents
… he was talkinga bout a security layer that had to do with getting to an authoritative DID Doc. So anything before that is a lower layer, where a lot of his concerns were
… that’s a space for interop amongst DID methods that might be where his concerns are
… if that’s true there might be agreement that there’s other work to do there
… we don’t need to change the DID Doc layer, but talk about interop from a lower layer
… the DID doc is about another layer, after you have an authoritative DID doc, that you could write application layer code that will interop across the DID methods ocne you have the DID Doc
… that might be a breakthrough, we might have been talking about two different layers

Jonathan Holt: I really like json-ld, the context does provide some gorunding for meaning, for semantic interop
… I’m still stuck with why the semantic web failed with regards to the authoritive sources of the context
… I’m still struggling
… but I think I did see someone propose a @context being optional so I think it really is dependant on the underlying DID method

Manu Sporny: JSON-LD and Why I Hate the Semantic Web – http://manu.sporny.org/2014/json-ld-origins-2/

Jonathan Holt: something we can keep kicking the can down the road is the MIME types. If the mime type is JSON-LD then the @context describes, it really is the transformation or extended format
… trying to run my examples to see expanded vs compact
… it’s the resolver or an algorithmic expansion that has cached those @context attributes and properly expands it into a format which is JSON

Brent Zundel: The concerns so far: @context and whether it belongs in the DID spec
… Interop at the key layer rather than the DID method layer

Dave Longley: I don’t kno about the names for those layers, but you’ve got a layer when you’ve already got a DID document, and stuff that happens before that

Brent Zundel: That’s what I meant by key layer

Manu Sporny: That makes no sense, please change it :P

Manu Sporny: I agree that we may have had a breakthrough during the DID WG call based on Sams’ presentation

Drummond Reed: I agree that the names for the two layers are probably different. I’d call them the “pre-DID doc layer” and “DID doc layer”

Manu Sporny: The other person we’re missing is mike lodder

Dave Longley: +1 to drummond, that’s at least much better naming

Manu Sporny: I spent a bit of time with Sam last week trying to listen and understand where many of these concerns were coming from
… my hope is I do the same thing with mike lodder and anybody else who wants to
… Where I was coming from was trying to understand the mental model that’s leading to these concerns
… and then setting it up so as an editor I would be able to write whatever text would make the subset of the community that is concerned about this stuff happy

Manu Sporny: https://lists.w3.org/Archives/Public/public-did-wg/2020Jan/0013.html

Manu Sporny: but it lead to a series of concerns, disagreements and questions which I put in this email tha tI just sent to the list
… I do want to at least go through that list
… and see if we have agreement on at least the concerns from the json-only arguements and the json-ld arguements
… make sure we have disagreements down and make sure we’re asking the right questions
… I’m not going to go through tha tno wbut my hope is we’d be able to get some concrete things down that will help us during f2f planning

Brent Zundel: If anyone has things they’d like to propose as concerns, this is the purpose of the call

Michael Jones: I want to respond to markus’ question about whether DID representations can be converted
… they could be, but only by the issuer because only the issuer has the keys to create a new authoritative representation
… The other thing I think we need to come to agreement about is that we need to for the json representation do what many people have said which is let JSON be JSON
… in particular, you can add a entry to a structure by simply adding it
… it could be collision resistant like jwt names, it could be registered in a registry either run by IANA or W3C
… but you should not have to use a namespacing representation in order to add a method or a field to a JSON object

Dave Longley: +1 you don’t “have to” do that

Michael Jones: concisely you should be able to add a field to a JSON object by simply adding it

Dmitri Zagidulin: First, @context.. I want to clear up some confusion that has been brought up
… there’s confusion about the purpose of the context, and about the ?? problem
… The purpose - I want to remind everyone that the point of the context is not that there’s a schema mechanism, there are separate things for that, which is why context and linked data can go side by side with json schema
… It is a schema migration mechanism? And a way to shorten globally collision-free properties
… the Choice that seems to be presented so far is linked data is complicated, we propose JSON. that’s a false choice. We will always need schema migration mechanisms, and an extension mechanism
… The choice really is do we go for a n explicit mechanism which is a link to a context, or do we go to a schema migration mechanism and extension mechanism that is hidden behind a WG, registires, and tribal knowledge?
… Several people have brought up a potential security concern about being able to load contexts from the web
… An analogy - the eval statement in JavaScript
… the arguement being made we shouldn’t use context because they can be loaded off the web is very similar to use we shouldn’t use JS becuase it supports the eval statement
… in both cases the idea is the intent of loading contexts or eval is for development - edge cases, and there are ways to make it safer
… just like you use JavaScript without eval, normally, the normal assumption with context is that you do not load them from the web, you load them from cryptographically sound local cache
… Last thing about base58, several of the discussions about whether base58 vs base64 and should key material be human readable
… the arguement so far has been humans will never have to type them in in the course of regular day to day interaction
… I want to remind everyone that base58 is not useful for, we don’t expect people to be typing in their DIDs manually when logging, or their keys, but it does come in handy for paper backups and paper restores
… the backing up of a master key onto a paper printout or hammering it into metal, and then during recover actually typing it in
… that’s where human interface, readability, writeability becomes important. Don’t forget the restore part.

Brent Zundel: said profound things, lost forever

Manu Sporny: I wanted to go down concerns I’m hearing from other people
… Going to try to put some of those things in here
… The first concern I’m hearing is…
… as an implementer I shouldn’t have to understand the conceptual burden of JSON-LD. As an implementer I’m going to reject the DID spec because it uses JSON-LD and I’ll use a simpler spec

Manu Sporny: CONCERN: The JSON-LD model raises conceptual burden for implementers to the level that it will be rejected by any community that needs a JSON-only model.

Manu Sporny: the problem is: don’t make me think about it

Manu Sporny: CONCERN: The JSON-LD model raises implementation burden for implementers to the level that it will be rejected by any community that needs a JSON-only model.

Manu Sporny: That is, because you’re making me use json-ld my implementation is going to be so much more complicated as a result, I’ll have to write so much more code, get parsers, all this other tooling, that I don’t need an IoT environment
… Don’t force this json-ld model on me becuase I don’t need it

Manu Sporny: CONCERN: The JSON-LD model forces implementers using JSON-only toolchains to “do JSON-LD processing”.

Manu Sporny: Another concern is that people have to do JSON-LD processing even though you say I don’t, I don’t believe you, don’t tell me I don’t have to use JSON-LD I can see that I do
… those are cocners about why not JSON-LD
… I’m also hearing concerns about the JSON only approach

Manu Sporny: CONCERN: The JSON-only approach will lead to incompatible data models wrt. the JSON-LD data model.

Manu Sporny: The first, incompatible data model, there’s an arguement from the JSON only approach that we’ve got our own extensibility mechanism and we’re fine with jsonld people doing what they want, but don’t force us to do it, we’ve got our own mechanisms to do that and fundamentally that will lead to different data models in the end and that will result in interop issues

Manu Sporny: CONCERN: The JSON-only approach will lead to a different, incompatible extensibility model from JSON-LD which would create an interoperability rift between JSON-only processors and JSON-LD processors.

Manu Sporny: The next one has to do with extensibility model - not data model - how do you extend the JSON only DID Document? What mechanism do you use. We’ve seen people suggest that we should have a bucket for DID method specific things
… The other concern is a jSON-only approach will centralize the extensibility model
… someone has a really interseting feature for the core DID document, there’s concenr that you have to go through a WG or register it in some kind of registry that someone has to take a look at and if it’s in the core you’re gonna have to create a new WG for that

Manu Sporny: CONCERN: The JSON-only approach would centralize the extensibility model for DID Documents.

Manu Sporny: meaning we’ll lose the decentralized extensibility aspects
… Finally that JSON-only is going to lead to security vulnerabilities, because some subset of DID method implementers are going to implement a new field, like authorization, and it’s going to mean something different, they’ll put it in the base of the DID Doc, which will be okay, and because of that one DID method implementer is going to implement it one way and another will do it a different way and they’re not going to agree

Manu Sporny: CONCERN: The JSON-only approach will lead to security vulnerabilities because features will not be globally unambiguous.

Manu Sporny: They’ll disagree and as a result there will be a security vuln because some software will see authorization and do one thing, and othe rsoftware will do something else
… I poured through the threads, and discussion with sam smith, these are what I extracted as the base concerns

Brent Zundel: Does anyone have any additional concerns that haven’t been brought up?
… Does anyone disagree that something manu brought up is a concern

Oliver Terbu: I disagree that having a json only data model would decrease security and will introduce security vulneratbilities. We could introduce regsitries in the same we there is for DID methods
… I don’t see this as an issue

dbuc: I also don’t see that as a concern, and also think we can accomplish this with forward compat

Oliver Terbu: I believe that JSON-LD could decrease security which is different from what manu is saying

dbuc: Thankfully I don’t need a DOCTYPE version indicator anymore

Markus Sabadello: One of manu’s concerns was that this would lead to incompatible data models. I was wondering if everybody agrees that is the case? Goes back to my original question about encodings and whether it would be possible to convert in a way taht is lossless

dbuc: I guess HTML is fundamentally insecure now

Markus Sabadello: So we’r enot talking about just different encodings but different data models. I think that should be one of the first questions we should agree on, whether we agree that we are going to have different data models and not just different encodings

Ivan Herman: one thing I agree with the items manu put down
… one that i remember coming up in the discussion is the starting position that the DID Doc is ??? has too many things and instead of doing that that many of the features would be ?? verifiable credentail type

Dave Longley: dbuc: you get tracked all the time across the internet because of disagreement on what needs to happen with certain web-based JS APIs … i think this is a more apt comparison vs. a presentation layer technology

Brent Zundel: there’s a concern that the DID doc may be doing too many things, and a proposal that the additional things should be done by VCs in the DID Doc?

Ivan Herman: yes

dbuc: dlongley: that’s not a function of HTML

dbuc: that’s not a function of HTML’s versioning

Michael Jones: I have to drop off after this. I both believe that the JSON-only data model will result in incompatible representations from JSON-LD, and I believe that’s a feature

dbuc: Bad JS APIs and their deprecation is not tied to versioning

Michael Jones: we should embrace that and recognise that people want the overhead of json-ld and its namespaces they can do that

Dave Longley: dbuc: yes, i know – i’m saying HTML isn’t the best comparison, other Web APIs are.

Michael Jones: but if they don’t want that they should be freed from that burden
… let’s embrace the incompatibility and move on

Manu Sporny: -1 to pushing people to fail interop by design by using JSON-LD.

Drummond Reed: Thanks Amy

dbuc: HTML is a forward compatible markup model

dbuc: sub the tokenized tags with JSON props/values, and that’s the comparison

Manu Sporny: CBOR is not a 1-to-1 mapping of JSON :(

Drummond Reed: mike-lodder: An abstract data model will be represented as JSON or JSON-LD or in other formats

Oliver Terbu: second what mike said

Manu Sporny: CBOR has features that JSON does not

Drummond Reed: to remind folks that for this call is not to debate the things, it’s to agree on what we need to drill into in the meeting

Michael Lodder: manu - Whether base encoding is JSON or abstract data model language like UML doesn’t matter that much - since everyone is using JSON, I could use JSON as abstract data model for limited data we have here. Abstract data model, JSON as syntax for Abstract Data Model. JSON-LD is optional encoding for that. Then JSON-LD doesn’t get in your way.

Jonathan Holt: CONCERN: The JSON-LD approach will lead to security vulnerabilities because depends on existing http vulnerabilites

Manu Sporny: You can losslessly convert going from JSON to CBOR and back. You cannot always go from CBOR to JSON and back.

Brent Zundel: reviews the list of concerns
… The JSON-LD model raises conceptual burden for implementers to the level that it will be rejected by any community that needs a JSON-only model. Agree?
… disagree? None

Dave Longley: CONCERN: Some level of disagreement may actually be largely about conflating pre-DID document layer and DID document layers; this disagreement may go away if we see those as separate layers.

Brent Zundel: The JSON-LD model raises implementation burden for implementers to the level that it will be rejected by any community that does not want to pay that cost. Agreed.
… The JSON-LD model forces implementers using JSON-only toolchains to “do JSON-LD processing”. Agreed.
… The JSON-only approach will lead to incompatible data models wrt. the JSON-LD data model. Agreed.

Samuel Smith: We don’t have a separate mechanism within the DID spec for establishment of control authority. It is commingled in the DID Doc. See DID Peer as an example.

Brent Zundel: The JSON-only approach will lead to a different, incompatible extensibility model from JSON-LD which would create an interoperability rift between JSON-only processors and JSON-LD processors. Agreed.
… The JSON-only approach would centralize the extensibility model for DID Documents. Agreed.
… The JSON-only approach will lead to security vulnerabilities because features will not be globally unambiguous. Agreed.

Samuel Smith: My main concern is that adoption barriers of the JSON-LD are not worth the extensibility it provides only a small subset of implementations need more than a simple set of common authorizations (service endpoints, communication)

Brent Zundel: The JSON-LD approach will lead to security problems because it depends on existing HTTP vulnerabilities. Agreed.
… Some concerns may be about conflating DID doc layer and pre-DID doc layers. Agreed.

Brent Zundel: CONCERN: DID Document does too many things (additional stuff should be VCs)

Brent Zundel: Does anyone disagree about that concern? No.

Michael Lodder: yes

Brent Zundel: Brent felt that the question about should @context be required is mixed in with the other concerns and should not be separate.

Drummond Reed: mike-lodder: It is a concern by itself.

Brent Zundel: Any disagreement about @context being a separate concern?

Manu Sporny: It feels duplicative.

Amy Guy: It seems like all of the arguements for/against @context break down into all the listed concerns

Drummond Reed: mike-lodder: I want to make sure it doesn’t get lost. Wants to make sure it’s covered in the others.

Samuel Smith: One proposal is to use @context to message that JSON-LD semantics are to used or not used.

Brent Zundel: Will leave it on the list.

Dave Longley: I think that is presupposing a solution to the other concerns. I want to make sure it doesn’t get mixed up with others.

Manu Sporny: We may be hearing only from a minority of implementers.
… wondering how many folks are actually planning to implement or not.

Samuel Smith: Implementation concerns are not diminished by the number of implementers

Manu Sporny: wondering if the concern is a vocal minority of implementers or not

Manu Sporny: CONCERN: A vocal minority of implementers are driving the discussion and we should understand how many implementers are actually affected by this decision.

Brent Zundel: not sure if it’s a metaconcern or not

Ted Thibodeau Jr: Concerns are all valid, but there are degrees of concern and those are also valid. Comes down to level of how much people care.

Brent Zundel: likes that
… “Knowing how much people who care about these things care about them will help us reach closure.”

Manu Sporny: not sure if that capture the whole idea. It’s not just how much people care…

Ted Thibodeau Jr: A concern about a requirement may depend on whether it is a MUST or a MAY. That can affect the level of concern.

Dave Longley: a lot of people in the community participated in getting the spec to where it is today – changing it in a significant way may bring back those concerns that were previously worked through, we should be aware of that

Ted Thibodeau Jr: so the level of what people are worried about is different that a serious objection

Ivan Herman: The question is whether an WG member will formally object to something in the spec.
… why that is the case is secondary. The key is whether there is or is not an objection.

Manu Sporny: yes, worried about putting the nuclear option on the table when starting the conversation.

Manu Sporny: we want to reduce rage quits during this discussion.

Brent Zundel: Objection is the nuclear option. It could be useful to measure objection other than “rage quitting”.

Oliver Terbu: CONCERN: How can the spec ensure that the same DID can have different encodings after it has been created.

Oliver Terbu: CONCERN: How to ensure the did document of ONE specific DID can be provided in different encodings such as json-ld, json and cbor, after the did was created and even after key rotation?

Manu Sporny: There is an answer to that question when we use JSON-LD :)

Samuel Smith: It doesn

Ted Thibodeau Jr: I wonder if “provided in” shouldn’t just be “translated to”, which might be a third-party service, or server-option, or a client-option…

Oliver Terbu: +1 markus (that is exactly the concern)

Ivan Herman: +1 to oliver and markus that being a concern

Markus Sabadello: It is a concern that after the DID is created, will you be able to retrieve a DID document, can you retrieve it in only one data model or under multiple data models?

Samuel Smith: require JSON-LD once one has established control authority andy signed authorization statement in any encoring may be authoritative. Its the co-mingling of establishment information in a DID Doc which is not authoritative until after control establishment. This is the core security problem.

Brent Zundel: other concerns around this topic?

Drummond Reed: the ist included extensibility, there’s a concern about incompatible extensibility that .. the concern is that having different ways of extending a good thing or a bad thing?
… I seem to hear opinions on both sides
… maybe this is already covered but I didn’t see that explicitly

Brent Zundel: I think i’ts already covered
… anyone see it as a separate concern?

Samuel Smith: Punnting the problem to DID resolution is not a good solution. Did resolution merely provides a DID Doc. Its not end verifiable in an of itself. Extensibility at the authorization layer makes not contribution to security at the resolution layer.

Tobias Looker: One of the potential nuances around extensibility is the thought that JSON-only approaches may extend in a way that is not compatible with JSON-LD documents. So the concern is: how would those extensibility models would line up?

Brent Zundel: What I’m hearing is that the extensibility models are important, and that we definitely need to have a conversation about that.

Michael Lodder: a+

Brent Zundel: Anything else for this call?

Manu Sporny: We didn’t get to the list about disagreements and questions. Are we going to do that on Friday?

Brent Zundel: Not totally sure about the topic for the next call, but Brent will discuss with DanB.
… if not on this topic, then we will move on to metadata or matrix parameters.

Drummond Reed: mike-lodder: For some of these concerns, can each side give examples that are tied to real world use cases? It would be helpful.

Manu Sporny: +1 for useful use cases

Brent Zundel: That will be helpful when we get to the actual discussion, but we won’t try to do that on these prep calls, but at the F2F.