DID WG (Virtual) F2F Meeting, 4th Day — Minutes

Date: 2020-11-05

See also the Agenda and the IRC Log

Attendees

Present: Daniel Burnett, Wayne Chang, Amy Guy, Shigeya Suzuki, Justin Richer, Jonathan Holt, Manu Sporny, Brent Zundel, Ivan Herman, Eugeniu Rusu, Tobias Looker, Dave Longley, Adrian Gropper, Michael Jones, Joe Andrieu, Drummond Reed, Markus Sabadello, Dmitri Zagidulin, Phil Archer, Orie Steele, Juan Caballero, Kaliya Young, Daniel Hardman, Kristina Yasuda

Regrets:

Guests: Keiko Itakura, Jay Kishigami, Kazuaki Arai, Kinji Matsumara, Yuki Yamakami, Tomoaki Mizushima, Zoltan Kis

Chair: Daniel Burnett, Brent Zundel

Scribe(s): Amy Guy, Drummond Reed, Manu Sporny

Content:

Ivan Herman: See slides.

1. Introductory remarks

Daniel Burnett: let’s get started
… the agenda for today.. for the first session, we focus on the abstract data model. it’s a continuation of earlier conversation
… there has been discussion by chairs and editors
… that’s our focus for the first part, to see if we can make progress
… for the second part after the break we’re going to be looking at the original goals for the meeting and see how we did
… probably won’t take the full hour
… if we have time, the chairs will allocate that to what seems most appropriate at the time
… one option might be that we look at other topics we originally planned for issue working
… the very end of the day we have updates on our other work items
… One other comment before we start is about Consensus
… brent and I spend a lot of time talking about this
… There’s a nice description of Consensus in the process doc now

Daniel Burnett: https://www.w3.org/2020/Process-20200915/#Consensus

Daniel Burnett: Some history
… A friend of mine involved in w3c in the early days, told me some thing sI didn’t know
… when w3c was started, timbl and others were active in IETF, which has a long history of successful spec work
… but Tim was very frustrated by seeing the same thing happen there that happens in governmental type standards organisations
… where you can end up with voting, room packing and so on that can alienate a significant fraction of the community
… I’ve done plenty of work myself in IETF, most of the time rough consensus and running code works great, but I’ve seen some failures there
… W3C has a notion of strong consensus
… tries to get unanimity where possible, but not always possible
… the fallback is consensus
… which means agreement by a large portion of the group
… some abstentions are okay but we prefer not to have too many
… and we really strongly avoid strong oppositions
… we are encouraged to go for solutions that produce the weakest objections, not necessarily solutions that satisfy the majority
… even with that there are no guarantees
… the chairs have to make consensus calls sometimes
… sometimes say we need to move ahead
… but we are only allowed to do that after we have ensured that the group has made every effort to try to address a comment
… not just within the group, external comments and concerns as well
… I know for some of you it may be frustrating to see us waiting when you want a decision
… we would love a decision as well
… for any of you who have found yourselves on that minority side, you know how important it is that your concerns have been heard
… our goal in this session today is to make progress toward consensus, even if not unanimity

2. ADM Working Session

Ivan Herman: see slides.

Brent Zundel: we’re going to operate with two queues
… only unmute when you’re asked to speak
… we’re going to use the raise hand feature in zoom for the first queue and the IRC queue for the other
… please raise your hand in zoom if you would like to answer the following question
… What critical use case of yours does the current spec text prohibit that you assumed would be possible?
… explained the ground rules for the upcoming discussion
… we will manage two queues - one in Zoom and one in IRC
… the Zoom queue will be for people to answer the first two questions on the slide
… Q1: Which of your critical use cases will break if the spec text is changed as recommended?
… Q2: What alternative spec text change should be made that would enable both use cases?
… Starting with the Zoom queue.

Dave Longley: The spec today does not let the JSON-only representation include an @context
… and wants a nice simple way to use the ADM
… wants the spec to say that @context MAY appear in the JSON-only representation
… and that if it appears there, the DID Core context must appear in the first position

Michael Jones: The use case of “letting JSON be JSON” will be broken if @context is included and must be processed. It MUST be ignored.

Manu Sporny: +1 to selfissued!!! :)

Brent Zundel: Not understanding how that is a critical use case for you.

Daniel Burnett: Mike, what use case of your will BREAK if we allow what Dave asked for. “Letting JSON be JSON” is not a use case.

Markus Sabadello: What might break is conversion from some representation to JSON-only representation if its unclear whether it may or may not have @context.

Michael Jones: The critical use case is using JSON-only processors that have no code for processing @context. Thus is MUST be ignored.
… so JSON-only MUST be able to ignore properties that it does not understand. That is the normal rule with JSON.
… we should not try to change the rule that’s already in place across the industry.

Dave Longley: clearly, JSON processors have to know about everything else we mention in the DID spec, @context would just be an “understood field”

Dave Longley: JSON processors don’t ignore everything they know about the things in the spec.

Joe Andrieu: +1 to dlongley’s point. that’s why @context is an “understood field” in the core properties

Dave Longley: well, JSON parsers would already ignore it, so +1 to that.

Dave Longley: obviously i do not advocate changing JSON parsers.

Jonathan Holt: The use case is representation-independent conversion.
… so the challenge is who is going to do substitution, expansion, replacement.
… is that the role of the resolver or the consumer.
… most of his concerns is about the security issues that may result.

Brent Zundel: What I am hearing is that David Longley wants to have the ability for @context to be in a DID document.
… it would require a consumer to preserve that property as it would with any other property.

Dmitri Zagidulin: +1 to brent.

Dave Longley: +1 to not singling out any particular property that is defined in the spec, but also +1 to not changing JSON.parse()

Michael Jones: The slippery-slope is that producer start putting it in JSON-only and requiring special rules, then it can become confusing.
… so the change that I would suggest is that JSON-only MUST ignore @context, i.e., no processing rules applied.

Brent Zundel: I believe we’re operating under an Open World data model, meaning that anyone can add any properties they want to a DID document
… in my understanding, a slippery slope would be to prohibit any properties explicitly
… as that will be unfeasible

Joe Andrieu: The problem here is that we established a grand compromise in Amsterdam and Mike’s position is not providing a way for both JSON-LD and JSON to co-exist in the DID ecosystem, which violates that compromise.

Orie Steele: Restating Mike’s proposal. Producers get to decide what properties is preserved, and any property NOT on that list should be preserved.

Michael Jones: That’s half of it. @context is special in that it has a special meaning in one representation. So it’s incumbent on us to define how this special member property must be treated.

Orie Steele: selfissued_ can you make a concrete proposal for language?

Orie Steele: its not clear what you mean by “ignore” ….

Michael Jones: therefore it is important to specify that @context MUST be ignored in the JSON-only representation

Brent Zundel: What do you mean by “ignore”?

Michael Jones: I don’t care if it’s preserved. But not processing must be performed.

Orie Steele: selfissued_ thats clear :)

Michael Jones: in the test suite, I would produce an @context with a boolean value and it should pass.

Orie Steele: I heard mike say: “we should allow "@context": true in did documents for application/did+json”

Proposed resolution: Add a test to the test suite for pure JSON in which an @context value of “true” is present and the test passes only if an error is not thrown. (Michael Jones)

Daniel Burnett: At a meta-level, please don’t talk about slippery slopes or theoretical observations. Please keep your statements very concrete about what you need.

Michael Jones: It is not theoretical that if some recipient process something and some don’t, you’ll have interop problems.

Manu Sporny: Clarifying question to Mike: would you expect the same thing to happen with an unknown property such as “foo”.
… would both be ignored and both be preserved.

Dave Longley: i think consumers MAY use it if it is understood and must ignore it if not

Dave Longley: ^is that acceptable?

Proposed resolution: @context/ MUST be “processed” by JSON Production or Consumption only when “understood”. (Orie Steele)

Michael Jones: “foo” is processed, according to past decisions, only if you understand it. Otherwise it is ignored.

Jonathan Holt: It would be helpful to leverage MIME types (content types) for each representation to instruct what processing needs to be done.
… for example, in the JSON-only content type, no JSON-LD or other processing occurs
… so if a DID document is requested in different content types, the appropriate processing is applied

Daniel Burnett: selfissued_, it sounds like you are saying that we must ignore @context regardless of whether the spec knows about it, but to process other properties if the spec knows about them. According to that definition you are treating @context differently yourself.

Manu Sporny: Still trying to decide what Mike means by “unknown”
… should “unknown” properties be ignored but preserved…
… or are you saying that “ignored” properties should be deleted

Michael Jones: we already had a proposal that “unknown properties must be preserved”
… I am not trying to change that for @context
… @context is not “unknown”, but the semantics in the JSON-only representation should treat it as ignored
… I have added a proposed test that an @context that has a boolean value passes the test because it’s preserved but ignored

Manu Sporny: Ok, at this point, I’m convinced that selfissued, dlongley, and I agree with one another.

Orie Steele: I agree with selfissued_ we know that JSON-only is CAPABLE being not valid JSON-LD, we should prove that with a test.

Manu Sporny: Ok, at this point, I’m convinced that Orie, selfissued, dlongley, and I agree with one another.

Dave Longley: I want to be sure that it’s okay to process @context if you understand it and decide you want to process it

Jonathan Holt: I now understand what Mike has suggested and now I think that it is okay to have it included
… I asked Cartsen Booerman (sp?) about properties like @context as “semantic sugar” and he said they have resisted them but there are use cases for them.

Manu Sporny: Update — jonathan_holt, Orie, selfissued, dlongley, and manu agree with one another.

Justin Richer: manu, it isn’t helpful to declare that other people agree with you without them saying so.

Orie Steele: justin_r its very helpful actually

Manu Sporny: justin_r — I’ll ask them to confirm

Justin Richer: then you all agree with me and we should prohibit @context in all forms :P

Orie Steele: let the people say they disapprove.

Manu Sporny: justin_r - I disagree with justin_r

Daniel Burnett: Justin, I believe manu is expressing his opinion and will verify it. This is very helpful

Dmitri Zagidulin: selfissued_ what do you mean by ‘coalesce opportunistically’? Not sure that makes sense..

Orie Steele: i don’t agree with you or find your comment helpful.

Michael Jones: Responding to David Longley, I believe that if you are a pure JSON processor, but you try to apply JSON-LD processing to a pure JSON document, you hurt interop.
… so that’s why he’s proposing to test for illegal values of @context.

Jonathan Holt: partially agree with the train of thought, we just need to tease out the details

Manu Sporny: I’ve been trying to track who agrees with who. Mike, Jonathan, Orie, David Longley, and Manu are on the same page.

Dave Longley: if you hand the DID Doc with @context to a “plain JSON processor” it should ignore @context, if you hand it to another type of processor, it may do something different.

Orie Steele: selfissued_ we agree with your proposal… the test.

Michael Jones: I’m not sure about the exact proposal.

Orie Steele: yes, we should have a similar test for CBOR

Orie Steele: big +1 to that

Markus Sabadello: I agree that an illegal value in @context should pass the test, but it can’t be converted

Orie Steele: the spec is broken today, the language is broken, and illogical… it both expects it and forbids it

Manu Sporny: it’s illegal per the spec today

Michael Jones: responding to Markus, you can transform this, you can move it in the abstract data model
… only when you populate it must be ignored in the ADM

Markus Sabadello: I agree

Justin Richer: what selfissued_ just said is something I’ve been asking for a while, what the behavior should be when there’s an existing context

Jonathan Holt: My reservation is still about the security concerns. If we push it to the resolvers, then I’m trusted the resolver to perform JSON-LD processing.
… that would be a fair compromise to allow @context to pass through.
… this came up in the discussion about constrained devices before
… as long as you “put an asterisk on there”, this compromise is okay

Dmitri Zagidulin: jonathan_holt - resolvers don’t do JSON-LD processing now, of any sort. I’m not quite sure what you’re referring to..

Justin Richer: will pass

Orie Steele: ^ dmitriz http resolvers like the universal resolver DO JSON-LD Processing, and in the future they may do “translation” as well… which I am very concerned about from a security perspective.

Dmitri Zagidulin: Orie - wait so.. the get() or resolve() function actually does json-ld processing, in the Universal Resolver?

Orie Steele: dmitriz yes in the universal resolver…. but its not defined as required per did core spec text today.

Dmitri Zagidulin: Orie - huh, did not know that. Thank you.

Orie Steele: glad thats been fixed ;)

Drummond Reed: I want to suggest a proposal on what is being agreed to would be helpful
… that would get something that we could all move on from
… if someone can put together that wording it would be helpful

Manu Sporny: would like Mike to run his proposal but clarify it to be running on a JSON representation

Jonathan Holt: or application/did+cbor

Manu Sporny: so it should not throw an error when the DID document is ingested in the JSON-only content type

Dave Longley: should not throw an error when the processor is a plain JSON processor

Michael Jones: I was not talking about the ADM, but the JSON-only representation.

Markus Sabadello: Orie and dmitriz, the Universal Resolver doesn’t do JSON-LD processing. It simply returns a JSON-LD DID document.

Orie Steele: … well it used to

Michael Jones: in that representation, it should not throw an error

Markus Sabadello: Orie yes it used to remove properties, but that should have been fixed now

Daniel Burnett: side conversations in IRC can be hard for others to follow
… as chairs we’ve let that go because it helps find consensus.
… if it’s not germane to the current conversation, it can be distracting

Jonathan Holt: did-document = { ? "@context" : "https://www.w3.org/ns/did/v1" / ["https://www.w3.org/ns/did/v1", 1*~uri ] / * }

Jonathan Holt: In handling this, CDDL would be helpful since we could constrain the types allowed.
… because we could specify the specific data types in the ADM
… this would help prevent nefarious activity

Michael Jones: MODIFIED PROPOSAL: Add a test to the test suite that includes “@context”: true when testing pure JSON implementations, which passes only if no error is thrown. The MIME type application/JSONcorresponds to pure JSON processing.

Proposed resolution: Add a test to the test suite that includes "@context": true when testing pure JSON implementations, which passes only if no error is thrown. The MIME type application/JSONcorresponds to pure JSON processing. (Brent Zundel)

Manu Sporny: +1

Orie Steele: +1

Dave Longley: +1

Markus Sabadello: +1

Eugeniu Rusu: +1

Drummond Reed: +1

Joe Andrieu: +1

Justin Richer: +1

Michael Jones: +1

Ivan Herman: +1

Tobias Looker: +1

Brent Zundel: +1

Shigeya Suzuki: +1

Amy Guy: +1

Dave Longley: +1

Dmitri Zagidulin: +1

Daniel Burnett: +1

Drummond Reed: +1

Eugeniu Rusu: +1

Jonathan Holt: +1, now “or application/cbor+did”

Joe Andrieu: +1

Resolution #1: Add a test to the test suite that includes "@context": true when testing pure JSON implementations, which passes only if no error is thrown. The MIME type application/JSONcorresponds to pure JSON processing.

Brent Zundel: we are resolved

Manu Sporny: This is currently in the spec — ”The member name @context MUST NOT be used as this property is reserved for JSON-LD producers.”

Manu Sporny: Just to clarify what this means in the spec, there are two sentences in the spec in the Core Representations, JSON-only part (see above)…
… I believe it means we should strike that sentence according to this proposal.

Manu Sporny: This is in the spec, and could stay — ”The value of the @context object member MUST be ignored as this is reserved for JSON-LD consumers.”

Manu Sporny: the other sentence manu just typed can stay provide that “ignore” means “preserve” as in “don’t do anything with it”

Proposed resolution: Change sentence to ““The member name @context MUST be ignored” (Michael Jones)

Drummond Reed: +1

Orie Steele: For consistency, should we add a similar proposal for a CBOR test

Manu Sporny: To be clear — I’d personally be fine w/ that.

Drummond Reed: I am also fine with that

Michael Jones: AMENDED PROPOSAL: Change sentence to ““The member name @context MUST be ignored by pure JSON processors”

Manu Sporny: I would be surprised if folks objected to treating CBOR differently from JSON with respect to this item.

Drummond Reed: Me too

Orie Steele: same

Manu Sporny: DID Resolution is out of scope for this WG :(

Jonathan Holt: I am expecting that if I’ve requested the JSON-LD content type, I’m expecting JSON-LD context processing has been done for me.
… same thing for CBOR

Orie Steele: manu so is “translating representations after they have been produced :)

Justin Richer: First wants to quickly explain why those statements got in there. On the production side, it was to avoid “mindless stuffing” of @context into JSON-only.

Jonathan Holt: +1 to justin_r

Manu Sporny: +1

Shigeya Suzuki: +1

Justin Richer: On the second statement, we need to define EXPLICITLY what it means to “ignore” and “preserve” a property.
… if it means to map it to an abstract data type in the ADM and then keep it, that’s fine, but let’s be explicit

Dmitri Zagidulin: +1

Justin Richer: that also means that if some other representation wants to use that property in their representation, they can do that

Manu Sporny: +1 to the definition that Justin just said.

Dave Longley: +1 to justin

Tobias Looker: +1 to being explicit

Justin Richer: but we need to be very explicit about what happens to properties in “all of these weird corner cases”

Brent Zundel: best way forward would be for someone to raise a PR with concrete spec text changes

Daniel Burnett: We are at a point where it might make sense to do live editing of spec text

Brent Zundel: Great idea. Let’s first deal with the queue quickly.

Michael Jones: I put an amended proposal for the sentence Manu suggested.
… to change that sentence to “The member name @context must be ignored by JSON-only processors.”

Tobias Looker: Or pure JSON consumers?

Michael Jones: I’m also fine with leaving the text as it is.

Justin Richer: not wordsmith, actually define

Tobias Looker: Is JSON processors the right language here?

Justin Richer: this was my previous attempt: https://github.com/w3c/did-core/pull/394

Tobias Looker: “JSON-only”

Brent Zundel: change is to “The member name @context must be ignored during consumption of a JSON-only representation”.

Proposed resolution: Unknown properties are added to the ADM by consumers using generic type processing rules per representation. Unknown properties are serialized by producers using generic type processing rules per representation. (Justin Richer)

Justin Richer: explains that he’s generalizing Mike’s proposal

Brent Zundel: we will stick with Mike’s proposal

Ivan Herman: Justin was faster. I agree with him. Thus we don’t have to have anything in the text if we used Justin’s proposal.
… because it simply says, “If a JSON process sees a property that is unknown, it is ignored and preserved.”

Justin Richer: I actually agree with selfissued_ that it should be an EXAMPLE

Markus Sabadello: +1 to ivan

Justin Richer: +1 to ivan

Michael Jones: I disagree. I agree with the part that it should be ignored and preserved, but we should call it out specifically because it is an understood property.

Orie Steele: +1 to ivan

Daniel Burnett: We can provide an informative note about @context.

Jonathan Holt: Just a note that the CBOR section will have conflicts if we do live editing.

Justin Richer: Completely agree with what Ivan and others have been saying here.
… the confusion is not just with the @context property.
… this should allow us to precisely enable an @context with a boolean value of “true” to be accepted
… and that should also apply to all other unknown properties
… and so if you see this special field that “@context”, we should have a note on that, but I’m trying to address the underlying issue

Dave Longley: if the property is in the DID spec or the DID spec registries, you must preserve it (do not delete it)

Michael Jones: I agree with your perspective, but I don’t want to see ADM references in the JSON-only section

Justin Richer: My proposal would go into the data model section.

Jonathan Holt: +1 to consistent solution across representations, how about CDDL?

Daniel Burnett: All, please refrain from the “if people would just review my PR” comments. We are trying to get consensus now, not identify who was right, wrong, or first.

Drummond Reed: I agree with what justin is saying
… the general rule would go in the description of the data model or the general reqs for all production of all representations
… I agree with Dan’s statement that we should, because @context is hard to say it’s not unknown because it’s defined by one representation, it’s very good idea to include a note in all the other representations reminding this property gets ignored as defined in the representation rules
… because it would help avoid developer confusion

Michael Jones: right now I’m trying to amend a specific sentence to change it as he wrote it just to establish consensus.
… but right now I’d like to edit this sentence.

Dave Longley: when translating from one representation to another — all properties defined in the DID spec and the DID spec registries must not be deleted

Brent Zundel: would like to run the proposal

Daniel Burnett: Agrees - let’s run the proposal. If it goes in, fine, if we then have a more general solution, then fine.

Brent Zundel: I am preparing a version of the proposal to clarify it.

Daniel Burnett: We can have both, even if one ends up unnecessary. It may be inelegant, but it’s not illegal

Proposed resolution: change the text from “The value of the @context object member MUST be ignored as this is reserved for JSON-LD consumers.” to “The value of the @context object member MUST be ignored.” (Brent Zundel)

Michael Jones: +1

Drummond Reed: +1

Orie Steele: +1

Manu Sporny: -1 not clear

Eugeniu Rusu: +1

Justin Richer: +0 it’s not necessary

Markus Sabadello: +1

Ivan Herman: -0.00005 (I feel it is unnecessary to have that in a normative text; the reference to @context should simply be removed. Won’t lie down on the road on this)

Kristina Yasuda: +1

Amy Guy: +1

Dave Longley: +1 as an improvement over the current text, but we need additional text or revised text to handle “ignored”

Shigeya Suzuki: +1

Joe Andrieu: -1 as confusing and misleading

Manu Sporny: we need to strike this language and address it as a general rule in the text. Working on that proposal.

Dave Longley: also agree with ivan and manu, wouldn’t want to leave what’s in the spec today, of course.

Manu Sporny: I would support a note that @context is to be ignored.

Michael Jones: The alternative is to keep it.

Proposed resolution: change the text from “The value of the @context object member MUST be ignored as this is reserved for JSON-LD consumers.” to a note “The value of the @context object member is to be be ignored.” (Brent Zundel)

Drummond Reed: +1 to adding “if present”

Ivan Herman: an informative note is different

Daniel Burnett: This style is acceptable

Amy Guy: Sorry no audio, I just want to confirm - I had though we were talking about “ The member name @context MUST NOT be used as this property is reserved for JSON-LD producers. “ which is in Production, but now we are proposing a change to “The value of the @context object member MUST be ignored as this is reserved for JSON-LD consumers. “ in Consumption, which already says what we want and doesn’t need to be removed. I thought Mike’s intent was for the former, not the latter. the one in consumption that already says “MUST BE ignored”

Ivan Herman: I won’t object

Jonathan Holt: This is focused on JSON-only right now. How does it affect the larger model.

Brent Zundel: We are addressing just JSON-only right now first.

Michael Jones: agrees with doing the more general thing later.
… fine with either proposal

Brent Zundel: let’s go with the reworded proposal

Proposed resolution: change the text from “The value of the @context object member MUST be ignored as this is reserved for JSON-LD consumers.” to “Note that the value of the @context object member will be ignored, if present.” (Brent Zundel)

Drummond Reed: +1

Michael Jones: +1

Manu Sporny: 0

Ivan Herman: +0.3

Eugeniu Rusu: +1

Orie Steele: +0

Brent Zundel: +1

Jonathan Holt: +0.5, contingent that we get to how this affects ADM

Amy Guy: +

Amy Guy: +1

Dave Longley: +1 improvement over current text

Justin Richer: +1 good enough

Manu Sporny: +0.1 — useless spec text for the most part — but clarifies for those really wondering about @context.

Tobias Looker: +1

Shigeya Suzuki: +1

Kristina Yasuda: +1

Markus Sabadello: +0.5

Resolution #2: change the text from “The value of the @context object member MUST be ignored as this is reserved for JSON-LD consumers.” to “Note that the value of the @context object member will be ignored, if present.”

Brent Zundel: No objections, we are resolved.
… asks Justin to repeat his proposal now

Tobias Looker: Does it make sense to talk about producers before consumers?

Tobias Looker: :)

Justin Richer: This is not proposing specific spec text—they need to be expanded to define “unknown property” and also what “generic type processing rules per representation”
… so the proposal is contingent on that caveat

Brent Zundel: please propose specific changes

Markus Sabadello: Doesn’t this depend on the representation, i.e., how a representation defines its production/consumption rules?

Justin Richer: This tries to capture the general production/consumption rules.
… it means that whenever you see a field, you need to convert both the name of the field and the value of the field, and you cannot convert it into a property that you know the definition of, then you need to just map it to an abstract data type in the ADM.
… this is why the definition of abstract data types in the ADM is so important

Brent Zundel: we are running out of time

Proposed resolution: Unknown properties are added to the Abstract Data Model by consumers using generic type processing rules per representation. Unknown properties are serialized by producers using generic type processing rules per representation. (Brent Zundel)

Drummond Reed: +1

Justin Richer: +1

Eugeniu Rusu: +1

Shigeya Suzuki: +1

Ivan Herman: +1

Manu Sporny: +1

Amy Guy: +1

Brent Zundel: +1

Dave Longley: +1

Jonathan Holt: 0, would like more clarification

Michael Jones: +1

Kaliya Young: +1

Dmitri Zagidulin: +1

Kristina Yasuda: +1

Tobias Looker: +1

Markus Sabadello: +1

Orie Steele: +0.5 not sure i fully understand

Resolution #3: Unknown properties are added to the Abstract Data Model by consumers using generic type processing rules per representation. Unknown properties are serialized by producers using generic type processing rules per representation.

Brent Zundel: No objections, we are resolved

Jonathan Holt: What does Justin think about the CDDL that Jonathan wrote about this.

Justin Richer: I think CDDL is fine. I don’t have a horse in that race. As chair of the COZY WG, we used CDDL for everything.

Michael Jones: The proposal is missing a statement about, “other than preserving it, it has no semantic effect”
… so the sentence as written is vague.

Manu Sporny: would it work with the rewording?

Michael Jones: done

Michael Jones: +1

Proposed resolution: The definition of “ignore a property during consumption” is to preserve the property in the Abstract Data Model using generic type processing rules per representation with no additional semantic processing performed. (Manu Sporny)

Eugeniu Rusu: +1

Dave Longley: +1

Orie Steele: +1

Manu Sporny: +1

Shigeya Suzuki: +1

Drummond Reed: +1

Kristina Yasuda: +1

Eugeniu Rusu: +1

Justin Richer: +0.5 sure

Tobias Looker: +1

Amy Guy: +1

Brent Zundel: +1

Ivan Herman: +1

Kaliya Young: +1

Jonathan Holt: +0.5, seems fine. I like to define processing rules

Markus Sabadello: 0

Resolution #4: The definition of “ignore a property during consumption” is to preserve the property in the Abstract Data Model using generic type processing rules per representation with no additional semantic processing performed.

Brent Zundel: No objections, we are resolved
… on break now. Next up is review goals and then next highest priorities.

3. face to face goals review

Daniel Burnett: we’d like to cover what we stated as goals we set out for the meeting, then decide what to do with the rest of the time

Ivan Herman: See slides.

Daniel Burnett: we have a couple of options
… goals were:
… to make clear what work remains before we can go to CR
… I believe we covered that, the chairs talked about the work and changes to process 2020 and IPR policy as well
… our primary goal was to resolve all major outstanding issues for the ADM and privacy concerns (by which we mean the type property and broader discussion around the avoidance of properties that provide personally identifiable information)
… the last item was to resolve at least a significant portion of remaining issues outside o fthe main ones
… I’d like to ask the editors if they believe we have covered the primary blocking issues regarding unknown unregistered/unloved/whatever properties
… or if there are other things that would be good to resolve in this meeting
… now you’re deciding whether we spend time on the abstract data model, or other issues we haven’t talked about yet

3.1. ADM discussions cont.

Manu Sporny: I believe we have consensus in the group but I’m concerned that what we’ve done could still be misinterpreted
… I tried to see if all the resolutions we made will result in a consistent spec
… I’m concerned when these PRs are raised we’ll get back into a degenerate case
… Markus was concerned about @context and its preservation in certain modes
… I’d like to hear from markus if he believes we have consensus and things are resolved
… and anyone else that didn’t actually speak up
… if you feel like there isn’t consensus around what happens with @context, specifically to make it a concrete discussion, it’d be good to hear from you
… the assertion right now is we have consensus and can have an internally consistent spec according to decisions we made today

Daniel Burnett: ground rules - we are just trying to understand if there is agreement with the consensus, no discussions about modifications
… you can ask questions but not go beyond that

Markus Sabadello: I don’t think there’s agreement
… I don’t think the spec will be internally consistent
… I could elaborate further
… on some things

Justin Richer: I think there’s agreement on what we have so far, there is not sufficiently complete discussion in order to have an internally consistent document
… there’s a lot that’s going to shake out in the details

Manu Sporny: I want to understand what isn’t done
… markus, I think you had a comment in github that really helped me understand where you were coming from
… I don’t know if you want to talk about that thing
… you made a number of assertions that were illuminating
… I don’t know if you feel like talking about that would be best.. it’s up to you
… I’m interested to hear where you feel like we don’t have consensus

Markus Sabadello: I can explain that more efficiently
… we agree that unknown properties must be preserved, we agree that @context is legal and must be ignored in plain JSON
… what i think is unclear is if we create DID documents through resolution or through translation from other representations in plain JSON or XML or something else
… do we think @context should be there or not?
… we’re saying if it’s there ignore it and it’s legal
… but will it be there or will it not be there, I don’t know that as an implementer
… the session today started today with the question about use cases
… this is something I cannot implement, if i create a DID doc in plain JSON, I don’t know whether I”m supposed to put @context there
… we have conflicting statements in DID core and the registries of whether @context is a core property or not
… it’s not listed as a core property
… when we had data and metadata, we listed a lot of properties in different buckets, created etc, nobody listed @context as a property that they want in the DID document
… it was always considered something that’s only JSON-LD specific
… I have two concrete proposals, either one of which is fine with me and would resolve the remaining issues

Daniel Burnett: is this the best use of our time right now?

Drummond Reed: +1 to running these proposals

Daniel Burnett: or to look at other issues?

Jonathan Holt: want to see proposals

Manu Sporny: we can’t do anything to the spec if there’s still disagreement

Drummond Reed: yeah I agree
… we can unblock stuff if we resolve these

Markus Sabadello: I have two

Markus sabadello: POSSIBLE PROPOSAL 1: - Remove text in DID Core that calls “@context” a “property”, and call it something else. - Remove “@context” from the list of properties in the DID Spec Registries. - Remove “@context” from CDDL.

Markus Sabadello: they are conflicting
… but I’d be fine with either

Markus sabadello: POSSIBLE PROPOSAL 2: - Add “@context” as a “Core Property” to DID Core, just like “service” or “verificationMethod” etc. - Keep “@context” in the list of a properties in DID Spec Registries. - Keep “@context” in CDDL.

Markus Sabadello: proposal 1 is to not call @context a property any more, it’s something very different
… the other proposal is to keep @context in the registries and CDDL and add it as a core property to DID core
… we need one or the other
… as an implementer I don’t know what i’m supposed to do with @context in representations other than JSON-LD … sometimes we treat it as something we need to preserve, and list in the registries
… but then we’re not saying it’s a core property
… I think we need to do one or the other

Drummond Reed: I have a slightly different proposal as to how to solve the question
… but I’d like to defer on that to see how conversation on his proposals plays out

Jonathan Holt: would love to have deep conversation on this, as I think it is really important

Manu Sporny: a counterbalance to what markus is saying - reminder, the spec started off and for years had @context as a thing that was in a DID document
… that was true for years
… it changed when the proposals to do multiple representations came around
… and slowly, it was moved out of the core properties section into the JSON-LD and JSON section, and then additional text was added to make it not be a “core property”
… i have a different view of what happened over the past couple of years
… just saying that there are multiple ways to view this, and one you can look at the github history and see how things change
… adding @context to the core properties, there’s a problem here whether there are two interpretations of what we mean by a property
… one is that a property is something that has a relationship with the DID subject
… another is what exists in the DID document
… there are arguments for and against either one
… an area we still have disconnect
… I value markus’ view of @context not being a core property, that is a new thing
… the decision we made today is it doesn’t matter how we classify this stuff
… people don’t care that much about the vigorousness of the ADM
… they just want to make sure @context sticks around so they can do things when it gets down to writing code
… that’s the concern I have
… we’re now getting ready to undo what we just did in the previous hour
… that’s gonna be bad

Justin Richer: to disagree with manu
… I see this as continuing what we are doing in the last hour

Drummond Reed: This is why my proposal (should we get to it) is to formally define in the spec “representation-independent properties” and “representation-specific properties”. If we do that, the rules become fairly straightforward.

Justin Richer: I want to support the idea of there being different slices of information as markus is proposal in proposal 1
… and so that the JSON-LD representation can explicitly call out @context as something it needs to know about and it needs to do special things with
… including creating it if the ADM doesn’t have one
… and correctly interpreting when you go to produce a serialisation in JSON-LD
… and also knowing what to do if for example there’s an @context with boolean true that had got chunked into the ADM, JSON-LDis going to need to know what to do with that to create a JSON-LD document properly
… I agree things have changed. we were correcting a bad assumption and a mistake previously in the document and we should continue down that road

Jonathan Holt: this is a really meaningful discussion
… if we explore a specific example - a did resolver requesting application/did+ld+JSON and that underlying DID method doesn’t have it, they don’t specify an @context, how to handle that use case
… and to specify that ..does that throw an error? because that underlying did method doesn’t support it it’s not an option?
… this could be easily resolved by how to handle this at did resolution when we deal with mime types

Michael Jones: in JSON-LD@context is not a property
… it’s part of the syntax
… saying what the properties are but it itself is not a property

Dave Longley: I think a JSON-LD consumer should throw an error if @context isn’t an array with DID core context as the first item, so @context would cause an error to be thrown

Orie Steele: See [understanding json-schema on properties](https://json-schema.org/understanding-json-schema/reference/object.html#:~:text=The%20properties%20(key%2Dvalue%20pairs,used%20to%20validate%20that%20property.&text=The%20additionalProperties%20keyword%20may%20be%20either%20a%20boolean%20or%20an%20object).
The properties (key-value pairs) on an object are defined using the properties keyword. In JSON, all “key-value” pairs are called “properties”…. lets not try and redefine JSON….

Michael Jones: I’ll note that in a context file @context doesn’t appear, whereas the property names do appear
… even in JSON-LD@context is not a property and we shouldn’t call it that, it’s syntax

Markus Sabadello: my understanding was what mike just said
… JSON-LD@context itself is not a property
… for me it would be fine to add it back as a core property but you know what we’re saying that all ..
… in DID core it says anything you can represent in a did document data model can be represented in any compliant DID doc
… means @context will be in every representation
… if we don’t do that then we should call it something else

Daniel Burnett: please nobody else join the q, at that point I’d like to switch the conversation to talking about possibly other naming
… drummond had a proposal for that. let’s see where that goes

Orie Steele: either of the proposals could lead to a solution that would be acceptable
… questions around the requirement of @context if it were a core property it would obviously have to be optional
… the bucketing name for non core properties that are still understood and described, we need a nice name for that bucket

Brent Zundel: all core properties are optional except for id

Orie Steele: generally in favour of proceeding down both of those paths (not both at once)

Ivan Herman: i want to go back to one comment that markus had
… that it is unclear what implementations should do with this different format
… i was wondering whether analogy helps here
… http and content negotiation, if i send a get request i can give the mime types that i want to get back and maybe several ones with a priority order
… and the response i get depends on what the server can do and how the server can honour the priorities i was asking for
… this is what happens here, depending on the method may or may not be able to do JSON-LD or JSON only
… and then i can communicate with the method with my preferences and this is the mechanism that should be there
… for me i must admit that means that whatever is necessary for that content negotiation is different than the content itself
… just like in the http case
… that for me gives an analogy

Orie Steele: ivan please review: https://github.com/w3c/did-core/issues/417
this issue addresses this exact cncern

Daniel Burnett: couple of people have raised this notion of a bucket
… markus put two proposals in, manu has one proposal
… let’s go back to the first two that markus put it
… anyone who believes they cannot give a response on those two proposals without discussing a bucket that’s other than required core properties or not a core property?
… manu is proposing optional core properties, I want to see if there’s anyone who is unwilling to give a response on markus’ original proposals without discussing this other category option?
… I’ll run markus’ two proposals

Drummond Reed: not objecting, just not sure how I’m gonna vote cos I’m not sure it casts the problem in the right way. maybe run them anyway

Proposed resolution: - Remove text in DID Core that calls “@context” a “property”, and call it something else. - Remove “@context” from the list of properties in the DID Spec Registries. - Remove “@context” from CDDL. (Markus Sabadello)

Justin Richer: +1

Manu Sporny: -1, prefer the other proposal

Markus Sabadello: +1

Michael Jones: +1

Jonathan Holt: is processing ….

Drummond Reed: +1

Eugeniu Rusu: +1

Ivan Herman: +1

Orie Steele: -1

Dmitri Zagidulin: -1, property is a generic enough name, and all our examples are in JSON

Shigeya Suzuki: 0

Phil Archer: is struggling…

Jonathan Holt: is processing ….

Dave Longley: -0

Kristina Yasuda: +1

Jonathan Holt: +0.5

Amy Guy: also processing, not sure, maybe 0…

Brent Zundel: 0

Tobias Looker: 0

Daniel Burnett: obviously not resolved, but there is some input

Proposed resolution: - Add “@context” as a “Core Property” to DID Core, just like “service” or “verificationMethod” etc. - Keep “@context” in the list of a properties in DID Spec Registries. - Keep “@context” in CDDL. (Markus Sabadello)

Manu Sporny: +1

Michael Jones: -1

Ivan Herman: -1

Markus Sabadello: +0.5 Prefer the other one but I can live with this too.

Justin Richer: -1 this conflates the purpose

Orie Steele: -1

Amy Guy: 0

Drummond Reed: -1

Dave Longley: -0

Brent Zundel: 0

Shigeya Suzuki: +0.5

Jonathan Holt: 0, don’t think it is at the same caliber as other core properties

Eugeniu Rusu: -0.5

Phil Archer: -1 I think we agreed @context is not a property, no?

Tobias Looker: 0

Kristina Yasuda: -1

Daniel Burnett: evenly split, very nice

Orie Steele: my reason for -1, is that the spec is not easier to use with either of these changes…

Michael Jones: As we discussed, @context is JSON-LD syntax - not a property

Proposed resolution: 1) The DID Core spec Core Properties section shall define “representation-independent properties”; 2) each Representation MAY define its own “representation-specific” properties, and 3) the ADM section should define how representation-specific properties are handled if they appear in a representation other than the one in which they are defined (“representation-foreign properties”). (Drummond Reed)

Drummond Reed: having run those previous two, this proposal will be a simple way of looking at it
… @context appearing in JSONonly or cddl or yaml would be a representation-foreign property and we say here is what you do

Kristina Yasuda: this is a good summary

Michael Jones: I can’t live with that wording because @context is JSON-LD syntax, it’s not a property
… it’s a reference to context files that lists properties but it’s not a property in of itself

Drummond Reed: representation specific syntax?

Orie Steele: mike… its a property in a JSON object.

Orie Steele: how can you possibly not see that?

Michael Jones: that’s fine as long as it lives in the JSON-LD section and not the abstract data model section
… it can define whatever syntax it wants

Jonathan Holt: I found Carsten’s comment helpful from our thread discussing this: https://github.com/w3c/did-spec-registries/pull/138#issuecomment-721624293

Drummond Reed: the thing that gets tricky is when it gets.. i’ll update it

Proposed resolution: 1) The DID Core spec Core Properties section shall define “representation-independent properties”; 2) each Representation MAY define its own “representation-specific” syntax, and 3) the ADM section should define how representation-specific syntax is handled if they appear in a representation other than the one in which they are defined (“representation-foreign syntax”). (Drummond Reed)

Michael Jones: the core problem here is we’re considering a layering violation, calling something that are syntax properties at another level.. they may be JSON members at a JSON level, but they are not properties as we use the word

Phil Archer: I agree @context isn’t a property
… drummond’s proposal is a lot closer to what’s in my head
… sorry I’ve been absent this week
… my words are a long way from well informed
… i have heard conversation today around content negotiation and the potential value of that
… there was work done in another working group around content negotiation by profile
… this is not directly relevant but yo would ask a server, I don’t just want JSON I want JSON according this schema
… which would be an additional dimension for content negotiation
… the other thing i haven’t heard people talk about is that JSON-LD1.1 allows you to include an http link header that says here’s my context file
… in our work on resolving gs1 identifiers the payload that comes back is usually JSON but there’s a header with the context file
… @context does not appear in the JSON … you have to get it from an extra thing
… that completely divorces the context from the JSON payload, might get the group out of this hole

Markus Sabadello: to respond to drummonds proposal
… I would support this proposal

Drummond Reed: Corrected for grammar: “PROPOSAL: 1) The DID Core spec Core Properties section shall define “representation-independent properties”; 2) each Representation MAY define its own “representation-specific” syntax, and 3) the ADM section should define how representation-specific syntax is handled if it appears in a representation other than the one in which the syntax is defined (“representation-foreign syntax”).”

Markus Sabadello: i do agree with mike and phil and others that i would prefer not to consider @context a property but this proposal at least calls it something else than a service or verificationmethod
… still calls it a property which aligns with some people, but does differentiate
… i would support this compromise

Daniel Burnett: this is not about what we would prefer is ideal or theoretically fabulous, but what you can accomplish
… if property term bugs you you can think of it as metadata thing in a key value representation
… let’s not get too hung up on a word yet

Manu Sporny: I’m afraid that we’re over-engineering at this point
… this is making it way more complex than what’s necessary
… this decision, if we pick it up, I can hold my nose and do it, the decision will not change anything about an implementation

Brent Zundel: +1 to Manu

Manu Sporny: it will be a bunch of spec text we right, it will put things in different buckets and the way they are treated will be the exact same
… and it’s not going to change anything

Michael Jones: Good point @manu that resolutions that don’t change implementations are less than helpful

Manu Sporny: but as one of the people that has to do the editorial work it’s going to result in a spec that’s more complicated and doesn’t work differently than if we were to put everything in one bucket
… that said, i’ll hold my nose and not stand in the way of the proposal

Daniel Burnett: write either proposal in a way that would get better consensus

Manu Sporny: run the proposal.. drummond’s

Drummond Reed: I’ve been trying to update it to incorporate mike’s point about not calling it property
… this isn’t intended to be final language, but to see if there’s a position we can all agree to and then we adapt it to the spec
… I do get manu’s point about making it look like two buckets but what we have been calling properties but we’ve spent so much time on the differences and how those two buckets are treated that having the spec be clear about why there are two buckets an dhow to deal with one or the other is going to be worth it

Proposed resolution: 1) The DID Core spec Core Properties section shall define “representation-independent properties”; 2) each Representation MAY define its own “representation-specific syntax”, and 3) the ADM section should define how representation-specific syntax is handled if it appears in a representation other than the one in which the syntax is defined (“representation-foreign syntax”). (Drummond Reed)

Ivan Herman: +1 to drummond on making it worth it

Orie Steele: +1

Drummond Reed: Hmm. “Core Properties” and “Representation Properties” <== I could live with that

Jonathan Holt: yesterday or the day before talking about the expected output of JSON-LD processing being the expanded document form with the @context removed, very similar to xml, that is a mapping of properties to the did core abstract data model and/or any other expanded retrieved aliasing and did core registry additions, but it had a very specific syntax that will alleviate the confusion between JSON-LD and JSON with an @context that we don’t know what to do with

Proposed resolution: 1) The DID Core spec Core Properties section shall define “representation-independent properties”; 2) each Representation MAY define its own “representation-specific syntax”, and 3) the ADM section should define how representation-specific syntax is handled if it appears in a representation other than the one in which the syntax is defined (“representation-foreign syntax”). (Daniel Burnett)

Orie Steele: +1

Manu Sporny: +0 — only doing this because it may get the group unstuck, it’s over-engineering and extra complexity in the spec that doesn’t change implementations

Drummond Reed: +1

Markus Sabadello: +0.5 I’d prefer not calling @context a property, but this is better than what we have now

Ivan Herman: +1

Shigeya Suzuki: +1

Phil Archer: +1

Dave Longley: 0

Amy Guy: 0

Michael Jones: -1 Over-engineered

Brent Zundel: 0

Justin Richer: +1 (but bikeshed the specific names later)

Dmitri Zagidulin: 0

Tobias Looker: 0

Kristina Yasuda: 0

Drummond Reed: Happy to bikeshed the names later

Eugeniu Rusu: +0.5 Agree with Markus

Daniel Burnett: more support than anything else
… what i’m hearing from people who say it’s over-engineered, each one of them disagrees violently on which of the two alternatives to take
… it may be over-engineering. Remember ugly baby?

Jonathan Holt: 0, I think this could work for my expanded document form of JSON-LD with @context removed

Daniel Burnett: w’ere trying to make sure we can accomplish the use cases
… making it elegant is not the requirement right now
… mike you gave a -1 on this
… aside from disliking the over-engineering is this something you are unable to live with

Michael Jones: it could be improved by not muddying the properties and syntax into the same bucket

Justin Richer: …. but this is creating separate buckets??

Michael Jones: this is possibly some progress but we’re going to have to come back and refine it again
… so that syntax is not called a property

Tobias Looker: Yeah thats my question?

Dmitri Zagidulin: this proposal does not bundle them together it separates them

Tobias Looker: I thought you were saying the separate buckets was over-engineering?

Daniel Burnett: he’s objecting to the use of the word property for @context no matter what we put before the word property

Michael Jones: as long as @property is in the representation specific syntax bucket but that’s not what was said

Justin Richer: that is why we’re creating this bucket

Brent Zundel: we have to make the buckets before we put things in them

Justin Richer: we do need to bikeshed the names but not now

Drummond Reed: i’m in favour of bikeshedding the names
… the point is the two buckets

Daniel Burnett: mike i heard you say that this would be okay but we’d have to refine into more detail
… this doesn’t mean there isn’t more to do

Resolution #5: 1) The DID Core spec Core Properties section shall define “representation-independent properties”; 2) each Representation MAY define its own “representation-specific syntax”, and 3) the ADM section should define how representation-specific syntax is handled if it appears in a representation other than the one in which the syntax is defined (“representation-foreign syntax”).

Michael Jones: I’m fine with that

Drummond Reed: Thanks Mike.

Manu Sporny: my assumption there was that things in both buckets are treated the exact same
… there will be no language in the spec that treats @context differently from unknown property ‘foo’ differently from known property ‘authentication’
… they’re all going to be treated the same

Markus Sabadello: I’m not sure about that
… if they’d be all treated the same
… i think the assumption is @context would be in the bucket of the representation specific, where service or verificationmethod would be representation independent

Ivan Herman: what manu is asking the answer is yes and no
… what is a core property is a property that all representations, all implementations, any syntax, all the core properties are known and to be processed by all implementations
… other ones are defined and to be used only by the specific syntax or representation

Markus Sabadello: +1 to ivan, that’s exactly the difference

Ivan Herman: and all the other representations will ignore them
… that’s the difference for me

Drummond Reed: Ivan nails it

Justin Richer: +1 to ivan, that’s what I was going to point out

Daniel Burnett: Personally, +1 to ivan

Ivan Herman: that is true that a JSON implementation will do the same as it does today
… JSON-LD will do the same as today

Manu Sporny: That would be fine with me, as long as no one in the group disagrees.

Ivan Herman: this differentiation to understand what is going on in the spec is important, and that’s the main difference

Daniel Burnett: there’s some agreement showing up here

Drummond Reed: ivan nailed it, that’s exactly why the two buckets
… the concern manu has about how it would be treated different is not a problem. the reason is to be able to talk about with happens with the representation-specific syntax that’s different than a core property/representation-independent property
… but not to discriminate, but to be clear

Manu Sporny: to be clear, the reason I’m being difficult about this is we need to decide this. we need concrete spec text and I’m not going to allow the group to feel good about what we’ve accomplished today if we can’t put this to bed. I agree with what ivan said

Dave Longley: we need to be able to say, when processing a syntax member in the ADM, what do you do with it? … for example, if you want to produce JSON-LD, you take the @context property and compact the output to that

Manu Sporny: I’d like to see a proposal
… the goal here is to get the spec done
… and not to kick the can

Drummond Reed: I like Justin’s proposal

Manu Sporny: and deal with it in a pr later which will inevitably get -1s

Ivan Herman: i agree with the text that justin put there

Michael Jones: Justin’s proposal is a positive step forward

Proposed resolution: representation-independent properties are processed the same regardless of representation, representation-specific syntax is potentially treated differently depending on the representation. (Justin Richer)

Manu Sporny: -1, not specific enough

Drummond Reed: +1

Ivan Herman: +1

Michael Jones: +1

Eugeniu Rusu: +1

Kristina Yasuda: +1

Phil Archer: +1

Justin Richer: +1

Markus Sabadello: +1

Brent Zundel: +1

Orie Steele: +1

Shigeya Suzuki: +1

Tobias Looker: +1

Dave Longley: +1 and we should say how

Jonathan Holt: +1 seems fair statement

Amy Guy: +1 with notes for representation-specific properties

Tobias Looker: provided we qualify what different means

Daniel Burnett: manu wants to know the statement about potentially treated differently, you want to know how
… I think what others are saying you get to define that

Justin Richer: you get to define that.

Drummond Reed: I think we already answered that this morning

Justin Richer: specifically the idea that representations have certain fields that they care very much about and would want to do very specific things during the consumption and production process
… and therefore they get to decide what to do with them
… in that process

Dave Longley: if it’s not “your” representation syntax, you ignore and preserve and pass on that syntax, if it’s “your” representation syntax, “you” say what happens

Justin Richer: if it is not a representation syntax that you’re representation deals with you treat it as an unknown property and chuck it through like we talked about earlier

Manu Sporny: good please put that in the proposal

Proposed resolution: if it’s not “your” representation syntax, you ignore and preserve and pass on that syntax, if it’s “your” representation syntax, “you” say what happens (Justin Richer)

Ivan Herman: I think it was said… it ties back to what we discussed before my dinner
… because in case of @context it means exactly that for JSON that this is not a property or instruction which is in my syntax and therefore I will ignore it
… this is exactly how it maps

Drummond Reed: +1 to what Justin is saying. The order of control over representation-specific syntax is: 1) what the representation defines, 2) what the DID method specification defines, 3) what the DID controller defines.

Ivan Herman: makes the decision we made earlier today put in the right context (pun intended)

Manu Sporny: we need to be clear who is defining what
… before, we had the JSON only representation saying what should be done with @context and I believe now that is no longer true… I want to make absolutely sure

Ivan Herman: the JSON only representation @context is not in its bucket
… and it will ignore it
… that is what this said

Manu Sporny: that’s fine, i want to make sure everyone agrees
… we started this hour off with markus disagreeing, I want to make sure everyone is on board
… trying to make sure we all really agree to this stuff
… what justin started out with wasn’t enough, he added something that made it enough and we don’t have a proposal that ties all these things together

Orie Steele: i agree with what manu saying
… the people are saying “you get to decide” and not defining “you”
… my proposal is the did method producing a representation gets to decide
… I believe if someone is making a decision about what goes in a concrete representation and it’s not the DID method we’re doing something wrong here

Ivan Herman: +1 to dlongley (and brent, which is very close)

Drummond Reed: I’d like to see dave longley’s proposal run

Michael Jones: I’m responding to DID methods should define this stuff… in most cases the spec test about the representation should define this stuff

Drummond Reed: My proposal will address Mike’s point

Justin Richer: +1 this is defined by the representation definition

Jonathan Holt: not a property, not a representation syntax, but a semantic coercion type

Michael Jones: and methods should follow what the spec text about a representation say

Justin Richer: (which is what dlongley is saying I think)

Daniel Burnett: who decides is the crux - the did method or the representation definition in the spec?

Proposed resolution: Processing of representation-specific syntax are defined by their representation and only processed when that representation is used, when another representation is used, the representation-specific syntax is ignored and preserved and passed through the ADM. (Dave Longley)

Michael Jones: +1

Justin Richer: +1 it’s fine

Dave Longley: +1

Drummond Reed: +1

Manu Sporny: +1

Eugeniu Rusu: +1

Amy Guy: +1

Kristina Yasuda: +1

Brent Zundel: +1

Ivan Herman: +1

Shigeya Suzuki: +1

Orie Steele: +1

Dmitri Zagidulin: +1

Tobias Looker: +1

Markus Sabadello: -0.5

Phil Archer: 0

Jonathan Holt: 0, seems reasonable

Daniel Burnett: now… markus! we’ve gone to -0.5 to -1

Markus Sabadello: I don’t understand the last part, representation specific syntax is passed through the ADM

Dave Longley: what i meant by that is when you are consuming something you ingest the data, put it somewhere, when you produce something it comes back out in a representation. if it’s syntax that must be preserved you must preserve it and send it out so it can continue on so if you ever produce the representation for which that syntax is native it can be used

Markus Sabadello: also means syntax specific to one representation would end up in others

Drummond Reed: only if you ask for it

Markus Sabadello: okay..

Daniel Burnett: explain only if you ask for it

Dave Longley: you’re doing a translation from something that you have to some other representation. when it is present there that’s asking for it

Jonathan Holt: seems like my MIME accept proposal

Phil Archer: the reason I put a 0 for that is because I was concerned that it seems very gung ho to say if there’s something you don’t understand you should skip it. Often that is okay. but what i heard mike say is the @context thing mucks up a JSONthing (I’ve heard that before elsewhere)
… blandly saying if you don’t understand it ignore it it might screw things up in your processor designed to do one thing and you give it something else and it balks
… it’s a nice idea, good idea, support the aspiration, worried about in practice

Daniel Burnett: we came to a resolution specifically on that point that I do not want to renegotiate

Phil Archer: sorry

Daniel Burnett: the real question is whether dave was saying something different or additional from what we decided earlier

Markus Sabadello: I think I understand.. I don’t think it’s a good idea for a representation specific syntax to show up anywhere than that representation
… means @context in a yaml file, xml namespaces in a JSON file and so on

Dmitri Zagidulin: +1 re manu’s phrasing “is available to the processor”

Markus Sabadello: I wouldn’t like to see that but I can live with that

Resolution #6: Processing of representation-specific syntax are defined by their representation and only processed when that representation is used, when another representation is used, the representation-specific syntax is ignored and preserved and passed through the ADM.

Daniel Burnett: thank you thank you thank you thank you

Drummond Reed: I have one more proposal that would give us even further clarification

Daniel Burnett: I share manu’s concern when things go to Prs but this is more precise
… we are at the end of our session time
… which is also a miracle
… we need to switch to something else
… thank you again, I mean it
… let’s see if we can move forward with it
… when PRs come out to reflect this in the spec, everyone please if you are not sure about the conversation we had, please review the minutes and resolutions
… because as manu says hopefully this doesn’t get killed when it becomes a PR
… make sure that your points were covered but don’t introduce new sticking points if you don’t have to

Ivan Herman: another request.. before this PR comes in, it’s a central one and makes a lot of changes, can we try to close in some way or other as many PRs as we can out of the open ones
… there is such a network maze of different PRs that I am lost

Manu Sporny: ivan, as much as I appreciate that, we’re going to have to wait until the PR is in. We can’t close issues until the PRs are processed
… I did look at how many issues are affected by the ADM, not even the editors agree
… let’s push that off for now, let’s get the PRs in
… and what we just did today into a cohesive set of PRs and if it gets through we can see which issues they apply to

Daniel Burnett: my suggestion is that dave would leave that because he made the proposal

Daniel Burnett: mental shift now, take a deep breath

4. Other work items

4.1. Use case document

Phil Archer: https://w3c.github.io/did-use-cases/#actions

Phil Archer: Going to focus on one thing
… new pictures… check out the link above.
… some concerns — division between Actions wasn’t clear

Drummond Reed: I like these very much!

Phil Archer: under each of those level 2 headings, you will see a different SVG diagram — we’re not going to discuss them now… Joe and I have been back and forth, hope the flows are right, people might improve them.
… We have a number of PRs that are ready to go — we’re close!
… No new use cases!
… Please let me stop.
… Help me stop… DRUMMOND.

Daniel Burnett: Do you need anything else from the group?

Phil Archer: Joe and I are working on this — I welcome interest - had a lot of input from Adrian, Markus, and others… document is better for it.
… We want a conclusion.

Daniel Burnett: Any questions from the group?

Manu Sporny: None

Daniel Burnett: Thank you Phil.

4.2. Implementation Guide

Brent Zundel: The question was — we keep mentioning it — that it would be good to have, we don’t have a formal decision from the group that we’re doing that work, nor do we have anyone volunteering to make it happen.
… Until we can resolve those things, we can’t assume we’re going to have an Implementation Guide.

Drummond Reed: I know that I’ve been assigned, markus has been assigned, not putting up my hand - can’t be primary driver.
… I can be a contributor, but primary driver… that’s not me.

Daniel Burnett: Anyone else?
… If no one takes lead, it won’t happen.

Drummond Reed: I agree with Amy, and am very happy to help her

Daniel Burnett: Thank you to Amy and Drummond for volunteering to help — Amy said she could volunteer but doesn’t have content for it.
… Where that boundary is — might be sufficient to get this done.
… Moving along…

4.3. Rubric

Ivan Herman: See slide.

Daniel Hardman: I’ve been working on this with Joe, if he’s on — he can speak, if not, can speak to it.
… Rubric wasn’t making progress over summer, but once Aug/Sept hit, we were able to make progress.
… Joe and I have weekly meetings where we review various things to move this forward… had a batch of changes for Amy’s work… work at RWoT has advanced… editorial fixes to change type wording, but there are substantive change, broaden scope beyond pure decentralization to talk about other kinds of characteristics that are interesting to evaluate in a DID Method.
… Taking new approach for examples in Rubric, can speak to contributors — drafted new sections to Rubric for Security/Privacy — how would you think about evaluating DID Method for cybersecurity characteristics, privacy characteristics?
… In the current rubric document, RWOT document, approach taken was that Joe and some of his collaborators went out and studied 6 different DID Methods in detail, read the specs, picked six methods that were likely to exhibit interesting variety in certain cases.
… Then they scored them, abbreviated example for matrix looks like for scoring on this slide.
… Letter grades, not intended to be grade metaphor, letters for scoring, three columns are how does this method manifest in spec, network, etc.
… Problem with this is, it’s hard to talk about six DID Methods… we have 60 more… six methods don’t exhibit interesting variety on a particular criteria.
… did:ethr/did:holo share a lot in common, but just different smart contract — didn’t think this was optimal… want to reference dozens of DID Methods… would like, on any given criterion, evaluate methods that show interesting variety… deliberately look for methods that are different from each other… why rubric exists at all, why it highlights differences… instead of Editors providing examples, seek contributions from experts in their own method.
… It would be good to hear from you on your DID Method… there are many dozens of questions in the document, pick two or three… PRs from expert from did:foo method, here’s an example on how did:foo has interesting things on question 19, 20, and 32.
… Would like to see high in one quality, low in another quality, not just DID Method authors tooting their own horn, but showing that all methods make trade-offs.
… Wanted to walk through new sections briefly — in an hour or two, will have content I’m talking to as PR against repo.

Drummond Reed: This is awesome

Daniel Hardman: What we propose on security, went through comments, came up with 9 questions about cybersecurity related topics.

Ivan Herman: see slide on security

Daniel Hardman: Does a DID Method, how robust is crypto? Measure by bits of security…
… A DID Method might — crypto that provides 64-bits of security or 128-bits of security… what’s the minimum that an implementation has to support? What is the lowest bar?
… Is security vetted by experts and battle hardened, or is it brand new? Little risky until further review? How friendly is method to future proofing?
… Are self-certifying identifiers provided… Protections against DoS, hacking, legal cease and desist?
… Provable DID Document history?
… Code for method is published, has vulnerability disclosure mechanism, diffuse control… M of N mechanisms - threshold signatures, whether it supports FIPS regimes, etc.
… Red at bottom of slide is foremost in our mind, are these good questions, what’s missing, did we give good responses? Measure in an intelligent way? Interesting variety?
… Hopefully that seems like progress.

Wayne Chang: A few points on this, in favor of general direction/categories — can we lean to testable side of things… even bits of security, RSA vs. elliptic, differences there… can we adopt another framework —  … “Reviweed by experts” — very subjective…
… A lot of these have huge potential to go to subjectivity, but overall like general direction for categories.

Daniel Hardman: The rubric is already subjective, not intended to provide definitive answers… designed to generate thought provoking questions.
… The work of this group is not to say “method A is good and method B is not”
… The goal is to tease out questions… but the more measurable is better.

Justin Richer: Is it worthwhile to capture agility that’s baked into some of these methods? If someone always uses RSA, or always uses one elliptic curve, will have different impact on security posture of a lot of these.
… especially if some method is susceptible for algorithm substitution attack… “same algorithm from 2005”, that seems that could be captured and measured here.

Daniel Hardman: I’ve heard Manu and others articulate - lots of ways to do something is generally bad way to do things, that’s not surfaced in any of these criteria… I was saying something more specific, but that’s a broader take on that. Flexibility on it’s own is not bad from as security perspective, but there are bad ways to do flexibility. Measurement not judgement, measure the flexibility.
… There is a new section on privacy, not as much in it as security section… is it possible to set constraints on visibility of DIDs? Or is method inherently public? Interesting privacy question.

Ivan Herman: See slide on privacy.

Daniel Hardman: Is there some way of inferring that DID A and DID B are both controlled by same person, could possibly be fingerprint risk.
… Is there a best practice of partitioning DIDs into carefully chosen contexts… does DID undermine that to not partition, cost, hassle, technical reasons, encouragement towards or away from best practice.
… Deletion — possible to undo mistakes, how bad are mistakes if they can’t be undone… how does right to be forgotten work?
… Type and danger — serviceEndpoints — does DID Method give technical/policy/explanatory safeguards to prevent privacy mistakes?

Daniel Burnett: Thank you so much, great review.

Drummond Reed: Outstanding review, Daniel.

Daniel Burnett: We need to get to a FPWD Note for this document, we don’t have enough time today, do plan for some time in next few weeks to schedule a discussion on that.

Ivan Herman: We need section on security/privacy in the core spec document… we should refer to from those sections… part of the work, Horizontal review, separate document for users to evaluate methods along those lines is significant and reviwers should know about it.

5. closing

Daniel Burnett: This has been a good but probably tiring 4 days to do this work, cancelling all of the DID WG meethings next week.
… We are doing a Virtual Face to Face Recovery Times.
… Any last words?
… We came to some good decisions, and not just feel good decisions.

Adrian Gropper: Well done organizers!

Brent Zundel: +1 thanks to everyone!

Drummond Reed: We got good things done, need to go through categorized issues.

Ivan Herman: I’ll clean up meeting minutes tomorrow — please go through them… verify.

Daniel Burnett: With that, thank you, officially done!

Kristina Yasuda: breakfast

Kristina Yasuda: 5am here

Dmitri Zagidulin: @kristina, others from that timezone - that is intense! :)

Kristina Yasuda: that was great thank you everyone!

6. Resolutions