16:34:50 <RRSAgent> RRSAgent has joined #did
16:34:50 <RRSAgent> logging to https://www.w3.org/2020/11/05-did-irc
16:34:52 <Zakim> RRSAgent, make logs Public
16:34:53 <Zakim> please title this meeting ("meeting: ..."), ivan
16:35:24 <ivan> Meeting: DID WG (Virtual) F2F Meeting, 4th Day
16:35:24 <ivan> Chair: burn, brent
16:35:24 <ivan> Date: 2020-11-05
16:35:24 <ivan> Agenda: https://tinyurl.com/yydapmu3
16:35:24 <ivan> ivan has changed the topic to: Meeting Agenda 2020-11-05: https://tinyurl.com/yydapmu3
16:41:10 <burn> burn has joined #did
16:48:41 <burn> present+
16:49:13 <keiko> keiko has joined #did
16:53:21 <wayne> present+
16:53:27 <wayne> burn: u so prepared
16:55:37 <Mizushima> Mizushima has joined #DID
16:55:52 <rhiaro> present+
16:56:23 <keiko> guest+ Keiko Itakura
16:58:36 <shigeya> present+
16:59:27 <justin_r> justin_r has joined #did
16:59:35 <jonathan_holt> jonathan_holt has joined #did
16:59:37 <justin_r> present+
17:00:18 <justin_r>  /me imagine if we'd had emojis in the IRC days...
17:00:31 <agropper> agropper has joined #did
17:00:33 <jonathan_holt> present+ jonathan_holt
17:00:50 <justin_r> s/ \/me imagine if we'd had emojis in the IRC days...//
17:00:51 <manu> present+
17:00:52 <ivan> See [slides](https://docs.google.com/presentation/d/1RoE8E4y8S1j65EJaXZ8oihkduNbjTXXvdwtkzw961Xw/edit#slide=id.g9b7a7df111_1_82).
17:00:54 <brent> present+
17:00:56 <ivan> present+
17:01:26 <markus_sabadello> markus_sabadello has joined #did
17:01:29 <tplooker> tplooker has joined #did
17:01:29 <kazuakiarai> kazuakiarai has joined #did
17:02:03 <Eugeniu_Rusu> Eugeniu_Rusu has joined #did
17:02:06 <ivan> guests+ Keiko_Itakura
17:02:11 <ivan> guests+ Jay_Kishigami
17:02:12 <Eugeniu_Rusu> present+
17:02:22 <tplooker> present+
17:02:23 <ivan> guests+ Kazuaki_Arai
17:02:39 <dlongley> present+
17:02:40 <agropper> present+
17:02:41 <ivan> guests+ Kinji_Matsumara
17:02:57 <ivan> present+ Tomoaki_Mizushima
17:03:07 <jay> jay has joined #did
17:03:17 <ivan> guests+ Yuki_Yamakami
17:03:27 <ivan> guests+ Tomoaki_Mizushima
17:03:30 <rhiaro> scribe+
17:03:38 <rhiaro> burn: let's get started
17:03:56 <rhiaro> ... the agenda for today.. for the first session, we focus on the abstract data model. it's a continuation of earlier conversation
17:04:02 <rhiaro> ... there has beend iscussion by chairs and editors
17:04:04 <ivan> present+ manu
17:04:04 <ivan> present+ shigeya
17:04:04 <ivan> present+ tplooker
17:04:16 <rhiaro> ... that's our focus for the first part, to see if we can make progress
17:04:19 <kinjim> kinjim has joined #did
17:04:20 <ivan> zakim, who is here?
17:04:20 <Zakim> Present: burn, wayne, rhiaro, shigeya, justin_r, jonathan_holt, manu, brent, ivan, Eugeniu_Rusu, tplooker, dlongley, agropper, Tomoaki_Mizushima
17:04:23 <Zakim> On IRC I see kinjim, jay, Eugeniu_Rusu, kazuakiarai, tplooker, markus_sabadello, agropper, jonathan_holt, justin_r, Mizushima, keiko, burn, RRSAgent, Zakim, ivan, shigeya, yuki,
17:04:23 <Zakim> ... tzviya, yoshiaki, selfissued, dmitriz, brent, ChristopherA, deiu26, Travis_, faceface, dlongley, manu, hadleybeeman, wayne, bigbluehat, rhiaro
17:04:29 <rhiaro> ... for the second part after the brea we'r egoing to be looking at the original goals for the meeting and see how we did
17:04:33 <rhiaro> ... probably won't take the full hour
17:04:39 <tm> tm has joined #did
17:04:43 <rhiaro> ... if we have time, the chairs will allocate that to what seems most appropriate at the time
17:04:52 <rhiaro> ... one option might be that we look at other topics we originally planned for issue working
17:05:00 <rhiaro> ... the very end of the day we have updates on our other work items
17:05:04 <selfissued_> selfissued_ has joined #did
17:05:12 <selfissued_> present+
17:05:15 <rhiaro> ... One other comment before we start is about Consensus
17:05:15 <burn> https://www.w3.org/2020/Process-20200915/#Consensus
17:05:21 <ivan> present+ present+ JoeAndrieu
17:05:21 <rhiaro> ... brent and I spend a lot of time talking about this
17:05:25 <rhiaro> ... There's a nice description of Consensus in the process doc now
17:05:27 <ivan> present+ JoeAndrieu
17:05:30 <rhiaro> ... Some history
17:05:37 <ivan> present+ drummond
17:05:40 <rhiaro> ... A friend of mine involved in w3c in the early days, told me some thing sI didn't know
17:05:50 <rhiaro> ... when w3c was started, timbl and others were active in IETF, which has a long history of successful spec work
17:06:02 <rhiaro> ... but tim was very frustrated by seeing the same thing happen there that happens in governmental type standards organisations
17:06:06 <ivan> guests+ Zoltan_Kis
17:06:15 <rhiaro> ... where you can end up with voting, room packing and so on that can alienate a significant fraction of the community
17:06:30 <rhiaro> ... I've done plneyt of work myself in IETF, most of the time rough consensus and running code works great, but I've seen some failures there
17:06:35 <rhiaro> ... W3C has a notion of strong consensus
17:06:42 <rhiaro> ... tries to get unanimity where possible, but not always possible
17:06:45 <rhiaro> ... the fallback is consensus
17:06:51 <rhiaro> ... which means agremeent by a large portion of the group
17:06:58 <rhiaro> ... some abstentions are okay but we prefer not to have too many
17:07:06 <rhiaro> ... and we really strongly avoid strong oppositions
17:07:23 <rhiaro> ... we are encouraged to go for solutions that produce the weakest objections, not necessarily solutions that satisfy the majority
17:07:28 <rhiaro> ... even with that there are no guarantees
17:07:32 <rhiaro> ... the chairs have to make consensus calls sometimes
17:07:36 <rhiaro> ... sometimes say we need to move ahead
17:07:48 <rhiaro> ... 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
17:07:55 <rhiaro> ... not just within the group, external comments and concerns as well
17:08:03 <rhiaro> ... I know for some of you it may be frustrating ot see us waiting when you want a decision
17:08:07 <rhiaro> .. .we would love a decision as well
17:08:21 <rhiaro> ... for any of you who have found yourselves on that minority side, you know how important it is that your concerns have been heard
17:08:33 <rhiaro> ... our goal in this session today is to make progress toward consensus, even if not unanimity
17:08:49 <rhiaro> scribe+ drummond
17:09:13 <rhiaro> brent: we're going to operate with two queues
17:09:14 <ivan> Topic: ADM Working Session
17:09:18 <rhiaro> ... only unmute when you're asked ot speak
17:09:21 <ivan> see [slides](https://docs.google.com/presentation/d/1RoE8E4y8S1j65EJaXZ8oihkduNbjTXXvdwtkzw961Xw/edit#slide=id.g9b7a7df111_1_94).
17:09:27 <rhiaro> ... we're going to use the raise hand feature in zoom for the first queue and the IRC queue for the other
17:09:41 <drummond> drummond has joined #did
17:09:43 <rhiaro> ... please raise your hand in zoom if you would like to answer the following question
17:09:47 <drummond> present+
17:09:53 <zkis> zkis has joined #did
17:09:57 <drummond> here now!
17:10:02 <drummond> scribe+
17:10:04 <drummond> Yes
17:10:26 <rhiaro> ... What critical use case of yours doe sthe current spec text prohibit that you assumed would be possible?
17:10:27 <drummond> brent: explained the ground rules for the upcoming discussion
17:10:29 <burn> q?
17:10:29 <ivan> present+ markus
17:10:45 <dmitriz> present+
17:10:45 <dlongley> q+
17:11:01 <dlongley> q-
17:11:23 <drummond> ...we will manage two queues - one in Zoom and one in IRC
17:11:26 <JoeAndrieu> JoeAndrieu has joined #did
17:11:38 <JoeAndrieu> present+
17:11:43 <drummond> ...the Zoom queue will be for people to answer the first two questions on the slide
17:12:24 <drummond> ... Q1: Which of your critical use cases will break if the spec text is changed as recommended?
17:12:38 <drummond> ...Q2: What alternative spec text change should be made that would enable both use cases?
17:13:10 <kinjim> kinjim has joined #did
17:13:18 <drummond> Starting with the Zoom queue.
17:13:42 <selfissued_> q+
17:13:47 <drummond> dlongley: The spec today does not let the JSON-only representation include an @context
17:14:07 <drummond> ...and wants a nice simple way to use the ADM
17:14:29 <drummond> ...wants the spec to say that @context MAY appear in the JSON-only representation
17:14:47 <phila> phila has joined #did
17:14:50 <markus_sabadello> q+
17:14:52 <brent> ack selfissued_
17:14:53 <drummond> ...and that if it appears there, the DID Core context must appear in the first position
17:14:55 <phila> present+
17:15:22 <manu> +1 to selfissued!!! :)
17:15:36 <drummond> selfissued_: The use case of "letting JSON be JSON" will be broken if @context is included and must be processed. It MUST be ignored.
17:16:04 <drummond> brent: Not understanding how that is a critical use case for you.
17:16:06 <selfissued_> q+
17:16:07 <brent> ack markus_sabadello
17:16:40 <burn> Mike, what use case of your will BREAK if we allow what Dave asked for.  "Letting JSON be JSON" is not a use case.
17:16:41 <drummond> 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.
17:16:44 <jonathan_holt> q+
17:16:46 <brent> ack selfissued_
17:17:33 <drummond> selfissued_: The critical use case is using JSON-only processors that have no code for processing @context. Thus is MUST be ignored.
17:18:02 <drummond> ...so JSON-only MUST be able to ignore properties that it does not understand. That is the normal rule with JSON.
17:18:13 <brent> ack jonathan_holt
17:18:14 <JoeAndrieu> +1 to dlongley's point. that's why @context is an "understood field" in the core properties
17:18:16 <drummond> ...we should not try to change the rule that's already in place across the industry.
17:18:23 <dlongley> clearly, JSON processors have to know about everything else we mention in the DID spec, `@context` would just be an "understood field"
17:18:25 <dlongley> JSON processors don't ignore *everything* they know about the things in the spec.
17:18:45 <drummond> jonathan_holt: The use case is representation-independent conversion.
17:18:50 <dlongley> well, JSON parsers would already ignore it, so +1 to that.
17:19:01 <drummond> ...so the challenge is who is going to do substitution, expansion, replacement.
17:19:05 <dlongley> obviously i do not advocate changing JSON parsers.
17:19:11 <Orie> Orie has joined #did
17:19:14 <drummond> ...is that the role of the resolver or the consumer.
17:19:16 <Orie> present+
17:19:30 <drummond> ...most of his concerns is about the security issues that may result.
17:19:45 <selfissued_> q+
17:19:59 <drummond> brent: What I am hearing is that David Longley wants to have the ability for @context to be in a DID document.
17:20:21 <drummond> ...it would require a consumer to preserve that property as it would with any other property.
17:20:41 <brent> ack selfissued_
17:20:51 <dmitriz> +1 to brent.
17:20:59 <dlongley> +1 to not singling out any particular property that is defined in the spec, but also +1 to not changing JSON.parse()
17:21:26 <drummond> selfissued_: The slippery-slope is that producer start putting it in JSON-only and requiring special rules, then it can become confusing.
17:21:41 <Orie> q+
17:21:56 <drummond> ...so the change that I would suggest is that JSON-only MUST ignore @context, i.e., no processing rules applied.
17:22:13 <burn> q+
17:22:30 <drummond> brent: I believe we're operating under an Open World data model, meaning that anyone can add any properties they want to a DID document
17:22:44 <JoeAndrieu> 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.
17:22:57 <drummond> ...in my understanding, a slippery slope would be to prohibit any properties explicitly
17:22:59 <selfissued_> q+
17:23:07 <justin_r> q+ to discuss the slippery slope
17:23:07 <drummond> ...as that will be unfeasible
17:23:09 <brent> ack Orie
17:24:10 <drummond> orie: Restating Mike's proposal. Producers get to decide what properties is preserved, and any property NOT on that list should be preserved.
17:24:51 <drummond> selfissued_: 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.
17:24:55 <burn> q?
17:25:05 <kristina> kristina has joined #did
17:25:06 <Orie> selfissued_ can you make a concrete proposal for language?
17:25:18 <Orie> its not clear what you mean by "ignore" ....
17:25:20 <drummond> ...therefore it is important to specify that @context MUST be ignored in the JSON-only representation
17:25:33 <drummond> brent: What do you mean by "ignore"?
17:25:55 <drummond> selfissued_: I dont' care if it's preserved. But not processing must be performed.
17:26:09 <Orie> selfissued_ thats clear :)
17:26:13 <Orie> thank you
17:26:25 <brent> ack burn
17:26:26 <manu> q+ to ask mike to clarify
17:26:26 <drummond> ...in the test suite, I would produce an @context with a boolean value and it should pass.
17:26:44 <Orie> I heard mike say: "we should allow @context: true in did documents for application/did+json"
17:26:49 <manu> q+ to ask -- Mike -- is `@context` treated in the exact same way as the undefined property `foo`?
17:26:51 <selfissued_> PROPOSAL: 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.
17:27:07 <jonathan_holt> q+
17:27:17 <brent> ack selfissued_
17:27:18 <drummond> burn: At a meta-level, please don't talk about slippery slopes or theoretical observations. Please keep your statements very concrete about what you need.
17:27:18 <justin_r> q-
17:27:48 <brent> ack manu
17:27:48 <Zakim> manu, you wanted to ask mike to clarify and to ask -- Mike -- is `@context` treated in the exact same way as the undefined property `foo`?
17:27:50 <drummond> selfissued_: It is not theoretical that if some recepient process something and some don't, you'll have interop problems.
17:28:20 <drummond> manu: Clarifying question to Mike: would you expect the same thing to happen with an unknown property such as "foo".
17:28:35 <drummond> ...would both be ignored and both be preserved.
17:28:51 <dlongley> i think consumers MAY use it if it is understood and must ignore it if not
17:28:53 <manu> q+
17:28:55 <brent> ack jonathan_holt
17:28:56 <dlongley> ^is that acceptable?
17:28:56 <Orie> PROPOSAL: @context/foo MUST be "processed" by JSON Production or Consumption only when "understood".
17:28:59 <drummond> selfissued_: "foo" is processed, according to past decisions, only if you understand it. Otherwise it is ignored.
17:29:36 <drummond> jonathan_holt: It would be helpful to leverage MIME types (content types) for each representation to instruct what processing needs to be done.
17:30:06 <drummond> ...for example, in the JSON-only content type, no JSON-LD or other processing occurs
17:30:08 <burn> 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.
17:30:57 <brent> q?
17:31:06 <brent> ack manu
17:31:12 <drummond> ...so if a DID document is requested in different content types, the appropriate processing is applied
17:31:29 <drummond> manu: Still trying to decide what Mike means by "unknown"
17:31:38 <selfissued_> q+
17:32:02 <drummond> ...should "unknown" properties be ignored but preserved...
17:32:20 <dlongley> q+ to ask if the above would be acceptable to mike
17:32:23 <drummond> ...or are you saying that "ignored" properties should be deleted
17:32:27 <brent> ack selfissued_
17:32:46 <drummond> selfissued_: we already had a proposal that "unknown properties must be preserved"
17:32:56 <drummond> ...I am not trying to change that for @context
17:33:40 <jonathan_holt> q+ to agree and clarify
17:33:42 <drummond> ...@context is not "unknown", but the semantics in the JSON-only representation should treat it as ignored
17:33:51 <manu> Ok, at this point, I'm convinced that  selfissued, dlongley, and I agree with one another.
17:34:07 <brent> ack dlongley
17:34:07 <Zakim> dlongley, you wanted to ask if the above would be acceptable to mike
17:34:10 <Orie> I agree with selfissued_ we know that JSON-only is CAPABLE being not valid JSON-LD, we should prove that with a test.
17:34:21 <drummond> ...I have added a proposed test that an @context that has a boolean value passes the test because it's preserved but ignored
17:34:26 <manu> Ok, at this point, I'm convinced that Orie, selfissued, dlongley, and I agree with one another.
17:34:35 <selfissued_> q+
17:34:46 <brent> ack jonathan_holt
17:34:46 <Zakim> jonathan_holt, you wanted to agree and clarify
17:35:04 <drummond> dlongley: I want to be sure that it's okay to process @context if you understand it and decide you want to process it
17:35:48 <drummond> jonathan_holt: I now understand what Mike has suggested and now I think that it is okay to have it included
17:36:21 <manu> Update -- jonathan_holt, Orie, selfissued, dlongley, and manu agree with one another.
17:36:28 <drummond> ...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.
17:36:31 <brent> ack selfissued_
17:36:42 <justin_r> manu, it isn't helpful to declare that other people agree with you without them saying so.
17:36:45 <manu> q+ to ask for people that disagree.
17:36:54 <Orie> justin_r its very helpful actually
17:37:08 <manu> justin_r -- I'll ask them to confirm
17:37:08 <justin_r> then you all agree with me and we should prohibit @context in all forms :P
17:37:10 <Orie> let the people say they disaprove.
17:37:19 <manu> justin_r - I disagree with justin_r
17:37:21 <burn> Justin, I believe manu is expressing his opinion and will verify it. This is very helpful
17:37:23 <dmitriz> selfissued_ what do you mean by 'coalesce opportunistically'? Not sure that makes sense..
17:37:23 <Orie> i don't agree with you or find your comment helpfyl.
17:37:24 <drummond> selfissued_: 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.
17:37:30 <brent> ack manu
17:37:30 <Zakim> manu, you wanted to ask for people that disagree.
17:37:47 <drummond> ...so that's why he's proposing to test for illegal values of @context.
17:38:13 <selfissued_> q+
17:38:16 <jonathan_holt> partially agree with the train of thought, we just need to tease out the details
17:38:22 <brent> ack selfissued_
17:38:29 <drummond> manu: I've been trying to track who agrees with who. Mike, Jonathan, Orie, David Longley, and Manu are on the same page.
17:38:38 <dlongley> 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.
17:38:40 <Orie> selfissued_ we agree with your proposal... the test.
17:38:47 <drummond> selfissued_: I'm not sure about the exact proposal.
17:39:09 <markus_sabadello> q+
17:39:22 <Orie> yes, we should have a similar test for CBOR
17:39:25 <Orie> big +1 to that
17:39:34 <brent> ack markus_sabadello
17:39:46 <manu> q+ to say that it's illegal today, per the spec.
17:40:06 <brent> ack manu
17:40:06 <Zakim> manu, you wanted to say that it's illegal today, per the spec.
17:40:08 <drummond> markus_sabadello: I agree that an illegal value in @context should pass the test, but it can't be converted
17:40:10 <selfissued_> q+
17:40:20 <Orie> the spec is broken today, the language is broken, and illogical... it both expects it and forbids it
17:40:25 <drummond> manu: it's illegal per the spec today
17:40:26 <markus_sabadello> q+
17:40:26 <jonathan_holt> q+
17:40:32 <brent> ack selfissued_
17:41:00 <drummond> selfissued_: responding to Markus, you can transform this, you can move it in the abstract data model
17:41:12 <drummond> ...only when you populate it must be ignored in the ADM
17:41:13 <justin_r> q+
17:41:16 <drummond> q+
17:41:24 <brent> ack markus_sabadello
17:41:32 <drummond> markus_sabadello: I agree
17:41:33 <brent> ack jonathan_holt
17:41:36 <justin_r> what selfissued_ just said is something I've been asking for a while, what the behavior should be when there's an existing context
17:41:43 <dlehn> dlehn has joined #did
17:42:19 <drummond> 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.
17:42:20 <manu> q+ to ask to run Mike's proposal.
17:42:38 <drummond> ...that would be a fair compromise to allow @context to pass through.
17:42:43 <selfissued_> q+
17:42:52 <dmitriz> jonathan_holt - resolvers don't do JSON-LD processing now, of any sort. I'm not quite sure what you're referring to..
17:42:58 <drummond> ...this came up in the discussion about constrained devices before
17:43:15 <brent> ack justin_r
17:43:19 <drummond> ...as long as you "put an asterisk on there", this compromise is okay
17:43:29 <drummond> justin_r: will pass
17:43:30 <brent> ack drummond
17:43:46 <Orie> ^ 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.
17:43:54 <rhiaro> drummond: I want to suggest a proposal on what is being agreed to would be helpful
17:43:58 <burn> q+ to ask people to keep side conversations directly relevant to main conversation
17:44:00 <jonathan_holt> q+
17:44:00 <rhiaro> ... that would get something that we could all move on from
17:44:12 <brent> ack manu
17:44:12 <Zakim> manu, you wanted to ask to run Mike's proposal.
17:44:12 <rhiaro> ... if someone can put together that wording it would be helpful
17:44:30 <dmitriz> Orie - wait so.. the get() or resolve() function actually does json-ld processing, in the Universal Resolver?
17:44:47 <drummond> manu: would like Mike to run his proposal but clarify it to be running on a JSON representation
17:44:52 <jonathan_holt> or application/did+cbor
17:44:59 <dlongley> should not throw an error when the processor is a plain JSON processor
17:45:04 <selfissued_> q+
17:45:08 <Orie> dmitriz yes in the universal resolver.... but its not defined as required per did core spec text today.
17:45:08 <brent> ack selfissued_
17:45:16 <drummond> ...so it should not throw an error when the DID document is ingested in the JSON-only content type
17:45:19 <dmitriz> Orie - huh, did not know that. Thank you.
17:45:34 <drummond> selfissued_: I was not talking about the ADM, but the JSON-only representation.
17:45:45 <markus_sabadello> Orie and dmitriz, the Universal Resolver doesn't do JSON-LD processing. It simply returns a JSON-LD DID document.
17:45:53 <Orie> ... well it used to
17:45:59 <Orie> glad thats been fixed ;)
17:46:02 <drummond> ...in that representation, it should not throw an error
17:46:04 <brent> ack burn
17:46:04 <Zakim> burn, you wanted to ask people to keep side conversations directly relevant to main conversation
17:46:15 <markus_sabadello> Orie yes it used to remove properties, but that should have been fixed now
17:46:25 <drummond> burn: side conversations in IRC can be hard for others to follow
17:46:43 <drummond> ...as chairs we've let that go because it helps find consensus.
17:46:57 <drummond> ...if it's not germaine to the current conversation, it can be distracting
17:46:58 <jonathan_holt> did-document = { ? @context : "https://www.w3.org/ns/did/v1" / ["https://www.w3.org/ns/did/v1", 1*~uri ] / * }
17:46:59 <brent> ack jonathan_holt
17:47:37 <drummond> jonathan_holt: In handling this, CDDL would be helpful since we could constrain the types allowed.
17:47:52 <selfissued_> MODIFIED PROPSAL: 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/json corresponds to pure JSON processing.
17:47:57 <drummond> ...because we could specify the specific data types in the ADM
17:48:19 <drummond> ...this would help prevent nefarious activity
17:48:52 <brent> PROPSAL: 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/json corresponds to pure JSON processing.
17:48:56 <manu> +1
17:48:57 <Orie> +1
17:48:58 <dlongley> +1
17:48:58 <markus_sabadello> +1
17:48:58 <Eugeniu_Rusu> +1
17:48:59 <drummond> +1
17:49:00 <JoeAndrieu> +1
17:49:00 <brent> 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/json corresponds to pure JSON processing.
17:49:04 <justin_r> +1
17:49:08 <selfissued_> +1
17:49:09 <tplooker> +1
17:49:09 <ivan> +1
17:49:09 <brent> +1
17:49:10 <shigeya> +1
17:49:13 <rhiaro> +1
17:49:18 <dlongley> +1
17:49:19 <dmitriz> +1
17:49:21 <burn> +1
17:49:22 <drummond> +1
17:49:32 <Eugeniu_Rusu> +1
17:49:45 <jonathan_holt> +1, now "or application/cbor+did"
17:49:52 <JoeAndrieu> +1
17:50:02 <brent> RESOLVED: 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/json corresponds to pure JSON processing.
17:50:05 <manu> q+ to note what this changes.
17:50:12 <drummond> brent: we are resolved
17:50:14 <Orie> q+
17:50:27 <brent> ack manu
17:50:27 <Zakim> manu, you wanted to note what this changes.
17:50:39 <jonathan_holt> q+
17:50:55 <manu> This is currently in the spec -- "The member name @context MUST NOT be used as this property is reserved for JSON-LD producers."
17:51:05 <drummond> manu: 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)...
17:51:10 <justin_r> q+ to talk about the reasoning behind those originally and how they fit now
17:51:13 <selfissued_> q+
17:51:27 <drummond> ...I believe it means we should strike that sentence according to this proposal.
17:51:34 <manu> 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."
17:51:48 <justin_r> q+ to discuss we need to explicitly define what "ignored" and "unknown" mean.
17:52:01 <drummond> ...the other sentence manu just typed can stay provide that "ignore" means "preserve" as in "don't do anything with it"
17:52:02 <selfissued_> PROPOSAL: Change sentence to ""The member name @context MUST be ignored"
17:52:04 <brent> ack Orie
17:52:04 <drummond> +1
17:52:04 <selfissued_> q+
17:52:27 <drummond> orie: For consistency, should we add a similar proposal for a CBOR test
17:52:38 <manu> To be clear -- I'd personally be fine w/ that.
17:52:45 <drummond> I am alos fine with that
17:52:46 <selfissued_> AMMENDED PROPOSAL: Change sentence to ""The member name @context MUST be ignored by pure JSON processors"
17:52:46 <brent> ack jonathan_holt
17:52:55 <manu> I would be surprised if folks objected to treating CBOR differently from JSON with respect to this item.
17:53:02 <drummond> Me too
17:53:04 <Orie> same
17:53:19 <manu> DID Resolution is out of scope for this WG :(
17:53:25 <ivan> q+
17:53:36 <drummond> 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.
17:53:42 <markus_sabadello> q+
17:53:44 <drummond> ...same thing for CBOR
17:53:49 <Orie> manu so is "translating representations after they have been produced :)
17:53:52 <brent> ack justin_r
17:53:52 <Zakim> justin_r, you wanted to talk about the reasoning behind those originally and how they fit now and to discuss we need to explicitly define what "ignored" and "unknown" mean.
17:54:53 <drummond> justin_r: 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.
17:55:03 <jonathan_holt> +1 to justin_r
17:55:12 <manu> +1
17:55:18 <shigeya> +1
17:55:23 <drummond> ...On the second statement, we need to define EXPLICITLY what it means to "ignore" and "preserve" a property.
17:55:42 <manu> +1 to the definition that Justin just said.
17:55:55 <drummond> ...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
17:56:11 <dlongley> +1 to justin
17:56:24 <dmitriz> +1
17:56:24 <drummond> ...that also means that if some other representation wants to use that property in their representation, they can do that
17:56:46 <burn> q+
17:56:49 <tplooker> +1 to being explicit
17:56:55 <burn> q-
17:56:56 <drummond> ...but we need to be very explicit about what happens to properties in "all of these weird corner cases"
17:57:14 <manu> q+ to define those things now
17:57:18 <drummond> brent: best way forward would be for someone to raise a PR with concrete spec text changes
17:57:41 <drummond> burn: We are at a point where it might make sense to do live editing of spec text
17:57:44 <ivan> q-
17:57:54 <drummond> brent: Great idea. Let's first deal with the queue quickly.
17:57:54 <brent> ack selfissued_
17:58:16 <drummond> selfissued_: I put an amended proposal for the sentence Manu suggested.
17:58:35 <justin_r> not wordsmith, actually define
17:58:37 <tplooker> Is JSON processors the right language here?
17:58:41 <drummond> ...to change that sentence to "The member name @context must be ignored by JSON-only processors."
17:58:54 <tplooker> Or pure JSON consumers?
17:59:03 <drummond> ...I'm also fine with leaving the text as it is.
17:59:15 <ivan> q+
17:59:34 <justin_r> this was my previous attempt: https://github.com/w3c/did-core/pull/394
17:59:41 <tplooker> "JSON-only"
17:59:41 <drummond> brent: change is to "The member name @context must be ignored during consumption of a JSON-only representation".
18:00:21 <selfissued_> q+
18:00:21 <jonathan_holt> q+
18:01:03 <justin_r> PROPOSAL: 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.
18:01:18 <justin_r> sorry, meant to emote that
18:01:55 <justin_r> q+
18:01:57 <drummond> justin_r: explains that he's generalizing Mike's proposal
18:02:06 <drummond> brent: we will stick with Mike's proposal
18:02:06 <brent> ack markus_sabadello
18:02:13 <brent> ack manu
18:02:13 <Zakim> manu, you wanted to define those things now
18:02:19 <brent> ack ivan
18:02:59 <drummond> ivan: Justin was faster for the second time. I agree with him. Thus we don't have to have anything in the text if we used Justin's proposal.
18:03:26 <drummond> ...because it simply says, "If a JSON process sees a property that is unknown, it is ignored and preserved."
18:03:28 <brent> ack selfissued_
18:03:57 <justin_r> I actually agree with selfissued_ that it should be an EXAMPLE
18:04:20 <markus_sabadello> +1 to ivan
18:04:25 <justin_r> +1 to ivan
18:04:30 <drummond> selfissued_: 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.
18:04:33 <Orie> +1 to ivan
18:04:36 <brent> q?
18:04:40 <brent> ack jonathan_holt
18:04:42 <selfissued_> q+
18:04:46 <drummond> burn: We can provide an informative note about @context.
18:04:48 <drummond> q+
18:05:06 <brent> ack justin_r
18:05:08 <drummond> jonathan_holt: Just a note that the CBOR section will have conflicts if we do live editing.
18:05:28 <drummond> justin_r: Completely agree with what Ivan and others have been saying here.
18:05:45 <drummond> ...the confusion is not just with the @context property.
18:06:05 <drummond> ...this should allow us to precisely enable an @context with a boolean value of "true" to be accepted
18:06:29 <drummond> ...and that should also apply to all other unknown properties
18:06:55 <brent> ack selfissued_
18:07:02 <drummond> ...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
18:07:23 <dlongley> if the property is in the DID spec or the DID spec registries, you must preserve it (do not delete it)
18:07:37 <drummond> selfissued_: I agree with your perspective, but I don't want to see ADM references in the JSON-only section
18:07:46 <selfissued_> q+
18:07:59 <drummond> justin_r: My proposal would go into the data model section.
18:08:01 <brent> ack drummond
18:08:06 <jonathan_holt> +1 to consistent solution across representations, how about CDDL?
18:08:08 <identitywoman> identitywoman has joined #did
18:08:10 <rhiaro> drummond: I agree with what justin is saying
18:08:18 <burn> 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.
18:08:24 <rhiaro> ... the general rule would go in the description of the data model or the general reqs for all production of all representations
18:08:49 <jonathan_holt> and yaml
18:09:02 <rhiaro> ... 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
18:09:06 <rhiaro> ... because it would help avoid developer confusion
18:09:08 <brent> q?
18:09:14 <drummond> thanks Amy
18:09:14 <brent> ack selfissued_
18:09:32 <burn> q+
18:09:55 <drummond> selfissued_: right now I'm trying to amend a specific sentence to change it as he wrote it just to establish consensus.
18:09:56 <dlongley> when translating from one representation to another -- all properties defined in the DID spec and the DID spec registries must not be deleted
18:10:05 <drummond> ...but right now I'd like to edit this sentence.
18:10:08 <brent> q?
18:10:13 <drummond> brent: would like to run the proposal
18:10:17 <brent> ack burn
18:10:47 <drummond> burn: Agrees - let's run the proposal. If it goes in, fine, if we then have a more general solution, then fine.
18:11:08 <drummond> brent: I am preparing a version of the proposal to clarify it.
18:11:26 <burn> We can have both, even if one ends up unnecessary.  It may be inelegant, but it's not illegal
18:12:09 <brent> q?
18:12:13 <brent> PROPOSAL: 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."
18:12:14 <selfissued_> +1
18:12:17 <drummond> +1
18:12:17 <Orie> +1
18:12:18 <manu> -1 not clear
18:12:19 <Eugeniu_Rusu> +1
18:12:19 <justin_r> +0 it's not necessary
18:12:20 <markus_sabadello> +1
18:12:21 <ivan> -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)
18:12:21 <kristina> +1
18:12:24 <rhiaro> +1
18:12:28 <dlongley> +1 as an improvement over the current text, but we need additional text or revised text to handle "ignored"
18:12:28 <shigeya> +1
18:12:29 <JoeAndrieu> -1 as confusing and misleading
18:12:48 <selfissued_> q+
18:13:24 <brent> ack selfissued_
18:13:30 <drummond> manu: we need to strike this language and address it as a general rule in the text. Working on that proposal.
18:13:44 <dlongley> also agree with ivan and manu, wouldn't want to leave what's in the spec today, of course.
18:13:48 <drummond> selfissued_: The alternative is to keep it.
18:14:00 <drummond> ...I would support a note that @context is to be ignored.
18:14:25 <brent> PROPOSAL: 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."
18:14:56 <brent> q?
18:14:56 <jonathan_holt> q+ to ask how this should be handled in the CBOR section?
18:15:06 <drummond> so Manu's a lawyer now ;-)
18:15:37 <ivan> q+
18:15:37 <drummond> +1 to adding "if present"
18:15:43 <rhiaro> q+ to say I though we were talking about " The member name @context MUST NOT be used as this property is reserved for JSON-LD producers. " in production rather than the one in consumption that already says "MUST BE ignored"
18:15:55 <brent> ack jonathan_holt
18:15:55 <Zakim> jonathan_holt, you wanted to ask how this should be handled in the CBOR section?
18:16:18 <brent> ack ivan
18:16:57 <drummond> ivan: an informative note is different
18:17:07 <drummond> burn: This style is acceptable
18:17:10 <brent> ack rhiaro
18:17:10 <Zakim> rhiaro, you wanted to say I though we were talking about " The member name @context MUST NOT be used as this property is reserved for JSON-LD producers. " in production rather than
18:17:11 <rhiaro> 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
18:17:11 <rhiaro> former, not the latter
18:17:13 <Zakim> ... the one in consumption that already says "MUST BE ignored"
18:17:13 <drummond> ivan: I won't object
18:17:16 <jonathan_holt> q+
18:17:37 <brent> ack jonathan_holt
18:17:48 <selfissued_> q+
18:17:59 <drummond> jonathan_holt: This is focused on JSON-only right now. How does it affect the larger model.
18:18:05 <brent> ack selfissued_
18:18:10 <drummond> brent: We are addressing just JSON-only right now first.
18:18:32 <drummond> selfissued_: agrees with doing the more general thing later.
18:18:37 <drummond> ...fine with either proposal
18:18:48 <drummond> brent: let's go with the reworded proposal
18:18:52 <brent> PROPOSAL: 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."
18:18:59 <drummond> +1
18:19:00 <selfissued_> +1
18:19:01 <manu> 0
18:19:02 <ivan> +0.3
18:19:05 <Eugeniu_Rusu> +1
18:19:06 <Orie> +0
18:19:09 <brent> +1
18:19:16 <jonathan_holt> +0.5, contingent that we get to how this affects ADM
18:19:18 <rhiaro> +
18:19:22 <rhiaro> +1
18:19:23 <dlongley> +1 improvement over current text
18:19:25 <justin_r> +1 good enough
18:19:28 <manu> +0.1 -- useless spec text for the most part -- but clarifies for those really wondering about @context.
18:19:28 <tplooker> +1
18:19:34 <shigeya> +1
18:19:51 <kristina> +1
18:19:59 <markus_sabadello> +0.5
18:20:15 <brent> RESOLVED: 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."
18:20:28 <drummond> brent: No objections, we are resolved.
18:20:45 <drummond> ...asks Justin to repeat his proposal now
18:21:04 <by_caballero__juan> by_caballero__juan has joined #did
18:21:06 <by_caballero__juan> present_
18:21:10 <by_caballero__juan> present+
18:21:22 <justin_r> q+
18:21:40 <brent> ack justin_r
18:22:02 <tplooker> Does it make sense to talk about producers before consumers?
18:22:21 <drummond> justin_r: 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"
18:22:25 <tplooker> :)
18:22:45 <drummond> ...so the proposal is contingent on that caveat
18:22:54 <drummond> brent: please propose specific changes
18:23:22 <markus_sabadello> q+
18:23:35 <brent> ack markus_sabadello
18:23:44 <justin_r> q+
18:24:01 <brent> ack justin_r
18:24:13 <drummond> markus_sabadello: Doesn't this depend on the representation, i.e., how a representation defines its production/consumption rules?
18:24:31 <drummond> justin_r: This tries to capture the general production/consumption rules.
18:25:43 <drummond> ...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.
18:25:58 <jonathan_holt> q+
18:26:00 <drummond> ...this is why the definition of abstract data types in the ADM is so important
18:26:11 <drummond> brent: we are running out of time
18:26:12 <manu> q+ to run one more proposal after this one.
18:26:22 <brent> PROPOSAL: 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.
18:26:27 <drummond> +1
18:26:27 <justin_r> +1
18:26:28 <Eugeniu_Rusu> +1
18:26:34 <shigeya> +1
18:26:35 <ivan> +1
18:26:35 <manu> +1
18:26:36 <rhiaro> +1
18:26:37 <brent> +1
18:26:37 <dlongley> +1
18:26:41 <jonathan_holt> 0, would like more clarification
18:26:41 <selfissued_> +1
18:26:42 <identitywoman> +1
18:26:42 <dmitriz> +1
18:26:46 <kristina> +1
18:26:51 <tplooker> +1
18:26:51 <ivan> present+ identitywoman
18:26:53 <markus_sabadello> +1
18:27:10 <drummond> Agreed
18:27:15 <brent> RESOLVED: 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.
18:27:18 <Orie> +0.5 not sure i fully understand
18:27:25 <drummond> brent: No objections, we are resolved
18:27:27 <brent> q?
18:27:35 <brent> ack
18:27:36 <brent> q+ to ask next steps
18:27:41 <brent> ack jonathan_holt
18:27:50 <drummond> jonathan_holt: What does Justin think about the CDDL that Jonathan wrote about this.
18:28:17 <brent> ack manu
18:28:17 <Zakim> manu, you wanted to run one more proposal after this one.
18:28:25 <drummond> justin_r: 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.
18:28:44 <selfissued_> q+
18:29:31 <brent> ack selfissued_
18:29:59 <drummond> selfissued_: The proposal is missing a statement about, "other than preserving it, it has no semantic effect"
18:30:20 <drummond> ...so the sentence as written is vague.
18:30:32 <drummond> manu: would it work with the rewording?
18:30:42 <drummond> selfissued_: done
18:30:48 <selfissued_> +1
18:30:48 <brent> PROPOSAL: 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.
18:30:48 <manu> PROPOSAL: 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.
18:30:49 <Eugeniu_Rusu> +1
18:30:50 <dlongley> +1
18:30:50 <Orie> +1
18:30:50 <manu> +1
18:30:52 <shigeya> +1
18:30:52 <drummond> +1
18:30:52 <kristina> +1
18:30:52 <Eugeniu_Rusu> +1
18:30:54 <justin_r> +0.5 sure
18:30:54 <tplooker> +1
18:30:55 <rhiaro> +1
18:30:59 <brent> +1
18:30:59 <ivan> +1
18:31:06 <identitywoman> +1
18:31:17 <jonathan_holt> +0.5, seems fine. I like to define processing rules
18:31:26 <markus_sabadello> 0
18:31:40 <brent> 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.
18:31:56 <drummond> brent: No objections, we are resolved
18:32:24 <drummond> ...on break now. Next up is review goals and then next highest priorities.
18:44:35 <manu> rrsagent, draft minutes
18:44:35 <RRSAgent> I have made the request to generate https://www.w3.org/2020/11/05-did-minutes.html manu
18:44:58 <manu> rrsagent, make logs public
18:45:04 <manu> rrsagent, draft minutes
18:45:04 <RRSAgent> I have made the request to generate https://www.w3.org/2020/11/05-did-minutes.html manu
18:57:01 <phila> phila has joined #did
19:02:15 <rhiaro> scribe+
19:02:33 <rhiaro> TOPIC: face to face goals review
19:02:47 <rhiaro> burn: 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
19:02:48 <ivan> See [slides](https://docs.google.com/presentation/d/1RoE8E4y8S1j65EJaXZ8oihkduNbjTXXvdwtkzw961Xw/edit#slide=id.g9b7a7df111_1_104).
19:02:51 <rhiaro> ... we have a couple of options
19:02:57 <rhiaro> ... goals were:
19:03:02 <rhiaro> ... to make clear what work remains before we can go to CR
19:03:13 <rhiaro> ... I believe we covered that, the chairs talked about the work and changes to process 2020 and IPR policy as well
19:03:43 <rhiaro> ... 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)
19:04:01 <rhiaro> ... the last item was to resolve at least a significant portion of remaining issues outside o fthe main ones
19:04:32 <rhiaro> ... I'd like to ask the editors if they believe we have covered the primary blocking issues regarding unknown unregistered/unloved/whatever properties
19:04:38 <rhiaro> ... or if there are other things that would be good to resolve in this meeting
19:04:43 <manu> q+ to ask Markus if he believes things are clear wrt. ADM
19:04:54 <brent> q-
19:04:58 <burn> ack brent
19:05:00 <rhiaro> ... now you're deciding whether we spend time on the abstract data model, or other issues we haven't tlaked about yet
19:05:05 <burn> ack manu
19:05:05 <Zakim> manu, you wanted to ask Markus if he believes things are clear wrt. ADM
19:05:06 <ivan> rrsagent, draft minutes
19:05:06 <RRSAgent> I have made the request to generate https://www.w3.org/2020/11/05-did-minutes.html ivan
19:05:22 <rhiaro> manu: I believe we have consensus in the group but I'm concerned that what we've done could still be misinterpreted
19:05:30 <rhiaro> ... I tried to see if all the resolutions we made will result in a consistent spec
19:05:39 <rhiaro> ... I'm concerned when these PRs are raised we'll get back intoa  degenerate case
19:05:47 <rhiaro> ... Markus was concerned about @context and its preservation in certain modes
19:05:50 <markus_sabadello> q+
19:05:56 <rhiaro> ... I'd like to hear from markus if he believes we have consensus and things are resolved
19:06:01 <rhiaro> ... and anyone else that didn't actually speak up
19:06:20 <rhiaro> ... 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
19:06:32 <rhiaro> ... the assertion right now is we have consensus and can have an internally consistent spec according to decisions we made today
19:06:46 <justin_r> q+
19:06:48 <rhiaro> burn: ground rules - we are just trying to understand if there is agreement with the consensus, no discussions about modifications
19:06:52 <rhiaro> ... you can ask questions but not go beyond that
19:06:56 <burn> ack markus_sabadello
19:07:00 <rhiaro> markus_sabadello: I don't think there's agreement
19:07:05 <rhiaro> ... I don't think the spec will be internally consistent
19:07:17 <rhiaro> ... I could elaborate further
19:07:27 <rhiaro> ... on some things
19:07:41 <burn> ack justin_r
19:07:58 <rhiaro> justin_r: 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
19:08:03 <rhiaro> ... there's a lot that's going to shake out in the details
19:08:20 <rhiaro> manu: I want to understand what isn't done
19:08:29 <rhiaro> ... markus, I think you had a comment in github that really helped me understand where you were coming from
19:08:33 <rhiaro> ... I don't know if you want to talk about that thing
19:08:39 <rhiaro> ... you made a number of assertions that were illuminating
19:08:46 <rhiaro> ... I don't know if you feel like taling about that would be best.. it's up to you
19:08:53 <rhiaro> ... I'm interested to hear where you feel like we don't have consensus
19:09:21 <rhiaro> markus_sabadello: I can explain that more efficiently
19:09:36 <rhiaro> ... we agree that unknown properties must be preserved, we agree that @context is legal and must be ignored in plain JSON
19:09:55 <rhiaro> ... 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
19:10:00 <rhiaro> ... do we think @context should be there or not?
19:10:05 <rhiaro> ... we're saying if it's there ignore it and i'ts legal
19:10:11 <rhiaro> ... but will it be there or will it not be there, I don't know that as an implementer
19:10:19 <rhiaro> ... the sesion today started today with the question about use cases
19:10:25 <ivan> q+
19:10:27 <drummond> q+ to propose an answer to Markus' question
19:10:32 <rhiaro> ... this is something I cannot implement, if i create a DID doc in plain JSON, I don't know whether I"m suppsoed to put @context there
19:10:45 <rhiaro> ... we have conflicting statements in DID core and the registries of whether @context is a core property or not
19:10:48 <rhiaro> ... it's not listed as a core property
19:11:05 <rhiaro> ... 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
19:11:11 <rhiaro> ... it was always considered something that's only JSON-LD specific
19:11:21 <rhiaro> ... I have two concrete proposals, either one of which is fine with me and would resolve the remaining issues
19:11:40 <rhiaro> burn: is this the best use of our time right now?
19:11:40 <drummond> +1 to running these proposals
19:11:46 <rhiaro> ... or to look at other issues?
19:11:46 <jonathan_holt> want to see proposals
19:11:55 <rhiaro> manu: we can't do anything to the spec if there's still disagreement
19:11:57 <rhiaro> drummond: yeah I agree
19:12:04 <ivan> q-
19:12:05 <rhiaro> ... we can unblock stuff if we resolve these
19:12:12 <rhiaro> markus_sabadello: I have two
19:12:26 <rhiaro> ... they are conflicting
19:12:29 <rhiaro> ... but I'd be fine with either
19:12:47 <manu> q+ to provide some background that disagrees with markus' view of history.
19:12:48 <rhiaro> ... proposal 1 is to not call @context a property any more, it's something very different
19:12:51 <justin_r> q+ to support multiple buckets
19:13:12 <rhiaro> ... the other proposal is to keep @context in the registries and CDDL and add it as a core property to DID core
19:13:15 <rhiaro> ... we need one or the other
19:13:25 <rhiaro> ... as an implementer I don't know what i'm supposed to do with @context in representations other than jsonld
19:13:31 <rhiaro> ... sometimes we treat it as something we need to preserve, and list in the registries
19:13:33 <burn> q?
19:13:35 <rhiaro> ... but then we're not saying it's a core property
19:13:40 <rhiaro> ... I think we need to do one or the other
19:13:44 <burn> ack drummond
19:13:44 <Zakim> drummond, you wanted to propose an answer to Markus' question
19:13:56 <rhiaro> drummond: I have a slightly different proposal as to how to solve the question
19:14:04 <rhiaro> ... but I'd like to defer on that to see how conversation on his proposals plays out
19:14:05 <burn> ack manu
19:14:05 <Zakim> manu, you wanted to provide some background that disagrees with markus' view of history.
19:14:23 <rhiaro> manu: 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
19:14:23 <jonathan_holt> would love to have deep conversation on this, as I think it is really important
19:14:25 <rhiaro> ... that was true for years
19:14:33 <rhiaro> ... it changed when the proposals to do multiple representations came around
19:14:51 <rhiaro> ... and slowly, it was moved out of the core properties section into the jsonld and json section, and then additional text was added to make it not be a "core property"
19:14:57 <rhiaro> ... i have a different view of what happened over the past couple of years
19:15:07 <rhiaro> ... just saying that there are multiple ways to view this, and one you can look at the github history and see how things change
19:15:21 <rhiaro> ... adding @context to the core properties, there's a problem here whethere there are two interpretations of what we mean by a property
19:15:27 <rhiaro> ... one is that a property is something that has a relationship with the DID subject
19:15:33 <rhiaro> ... another is what exists in the DID document
19:15:41 <rhiaro> ... ther eare arguements for and against either one
19:15:46 <rhiaro> ... an area we still have disconnect
19:15:56 <rhiaro> ... I value markus' view of @context not being a core property, that is a new thing
19:15:59 <selfissued_> present+
19:16:03 <rhiaro> ... the decisiosn we made today is it doesn't matter how we classify this stuff
19:16:09 <rhiaro> ... people dont' care that much about the vigorousness of the ADM
19:16:17 <ivan> q?
19:16:17 <rhiaro> ...they just want to make sure @context sticks around so they can do things when it gets down to writing code
19:16:20 <rhiaro> ... that's the concern I have
19:16:26 <rhiaro> ... we're now getting ready to undo what we just did in the previous hour
19:16:28 <rhiaro> ... that's gonna be bad
19:16:29 <burn> ack justin_r
19:16:29 <Zakim> justin_r, you wanted to support multiple buckets
19:16:36 <rhiaro> justin_r: to disagree iwth manu
19:16:40 <rhiaro> ... I see this as continuing what we are doing in the last hour
19:16:46 <drummond> 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.
19:16:50 <rhiaro> ... I want to support the idea of there being different slices of information as markus is proposal in proposal 1
19:17:03 <rhiaro> ... and so that the jsonld representation can explicitly call out @context as something it needs to know about and it needs to do special things with
19:17:08 <rhiaro> ... including creating it if the ADMdoesn't have one
19:17:15 <burn> q?
19:17:16 <rhiaro> ... and correctly interpreting when you go to produce a serialisation in jsonld
19:17:20 <jonathan_holt> q+
19:17:42 <rhiaro> ... and also knowing whta to do if for example there's an @context with boolean true that had got chunked into the ADM, jsonld is going to need to know what to do with that to create a jsonld document properly
19:17:48 <selfissued_> q+
19:17:53 <burn> ack jonathan_holt
19:17:55 <rhiaro> ... 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
19:18:01 <rhiaro> jonathan_holt: this is a really meaningful discussion
19:18:06 <markus_sabadello> q+
19:18:24 <rhiaro> ... 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
19:18:26 <Orie> q+ to discuss 'accept'
19:18:37 <rhiaro> ... and to specify that ..d oes that throw an error? because that underlying did method doens't support it it's not an option?
19:18:47 <ivan> q+
19:18:47 <burn> ack selfissued_
19:18:47 <rhiaro> ... this could be easily resolved by how to handle this at did resolution when we deal with mime types
19:18:58 <rhiaro> selfissued_: in jsonld @context is not a property
19:19:01 <rhiaro> ... it's part of the syntax
19:19:08 <rhiaro> ... saying what the properties are but it itself is not a property
19:19:09 <dlongley> 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": true` would cause an error to be thrown
19:19:17 <Orie> 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.
19:19:18 <rhiaro> ... I'll note that in a context file @context doesn't appear, wheras the property names do appear
19:19:25 <burn> q?
19:19:26 <Orie> > The properties (key-value pairs) on an object are defined using the properties keyword.
19:19:26 <rhiaro> ...e ven in jsonld @context is not a property and we shouldn't call it that, it's syntax
19:19:41 <burn> ack markus_sabadello
19:19:41 <jonathan_holt> thinks that is a good thing
19:19:53 <rhiaro> markus_sabadello: my understand was what mike just said
19:19:59 <rhiaro> ... jsonld @context itself is not a property
19:20:14 <rhiaro> ... for me it would be fine to add it back as a core property but you kno wwhat we're saying that all ..
19:20:26 <Orie> in JSON, all "key-value" pairs are called "properties".... lets not try and redefine JSON....
19:20:33 <rhiaro> ... in DID core it says anything you can represent in a did document data model can be represented in any compliant DID doc
19:20:40 <rhiaro> ... means @context will be in every representation
19:20:45 <rhiaro> ... if we don't do that then we should call it something else
19:21:09 <rhiaro> burn: please nobody else join the q, at that point I'd like to switch the conversation to talking about possibly other naming
19:21:15 <rhiaro> ... drummond had a proposal for that. let's see where that goes
19:21:16 <burn> ack Orie
19:21:16 <Zakim> Orie, you wanted to discuss 'accept'
19:21:28 <rhiaro> Orie: either of the proposals could lead to a solution that would be acceptible
19:21:37 <rhiaro> ... questions around the requirement of @context if it were a core property it would obviously have to be optional
19:21:48 <rhiaro> ... the bucketing name for non core properties that are still understood and described, we need a nice name for that bucket
19:21:49 <brent> all core properties are optional except for id
19:21:56 <burn> ack ivan
19:21:58 <rhiaro> ... generally in favour of proceeding down both of those paths (not both at once)
19:22:04 <rhiaro> ivan: i want to go back to one comment that markus had
19:22:11 <rhiaro> ... that it is unclear what implementations should do with this different format
19:22:17 <rhiaro> ... i was wondering whether analogy helps here
19:22:34 <rhiaro> ... 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
19:22:45 <rhiaro> ... and the response i get depensd on what the server can do and how the server can honour the priorities i was asking for
19:22:52 <markus_sabadello> q+
19:22:53 <Orie> ivan please review; https://github.com/w3c/did-core/issues/417
19:22:56 <rhiaro> ... this is what happens here, depending on the method may or may not be able to do jsonld or json only
19:23:00 <Orie> ^ this issue addresses this exact cncern
19:23:04 <markus_sabadello> q-
19:23:09 <rhiaro> ... and then i can communicate with the method with my preferences and this is the mechanism that should be there
19:23:20 <markus_sabadello> q+
19:23:21 <rhiaro> ... for me i must admit that means that whatever is necessary for that content negotiation is different than the content itself
19:23:25 <rhiaro> ... just like in the http case
19:23:29 <rhiaro> ... that for me gives an analogy
19:23:30 <manu> q+ to run both of Markus' proposals.
19:23:43 <rhiaro> burn: couple of peopel have raised this notion of a bucket
19:23:46 <markus_sabadello> q-
19:23:48 <rhiaro> ... markus put two proposals in, manu has one proposal
19:23:54 <rhiaro> ... let's go back to the first two that markus put it
19:24:09 <rhiaro> ... 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?
19:24:33 <rhiaro> ... 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 cateogry option?
19:24:45 <rhiaro> ... I'll run markus' two proposals
19:25:00 <rhiaro> drummond: 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
19:25:19 <markus_sabadello> PROPOSAL: - 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.
19:25:26 <justin_r> +1
19:25:28 <manu> -1, prefer the other proposal
19:25:29 <markus_sabadello> +1
19:25:29 <selfissued_> +1
19:25:29 <jonathan_holt> is processing ....
19:25:29 <drummond> +1
19:25:31 <Eugeniu_Rusu> +1
19:25:34 <ivan> +1
19:25:36 <Orie> -1
19:25:39 <dmitriz> -1, property is a generic enough name, and all our examples are in JSON
19:25:41 <shigeya> 0
19:25:42 <phila> ...is struggling
19:25:45 <jonathan_holt> is processing ....
19:25:53 <dlongley> -0
19:25:53 <kristina> +1
19:25:56 <jonathan_holt> +0.5
19:25:57 <rhiaro> ... also processing, not sure, maybe 0
19:26:01 <brent> 0
19:26:05 <tplooker> 0
19:26:06 <ivan> present+ phila
19:26:21 <rhiaro> burn: obviously not resolved, but there is some input
19:26:25 <markus_sabadello> PROPOSAL: - 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.
19:26:31 <manu> +1
19:26:34 <selfissued_> -1
19:26:34 <ivan> -1
19:26:40 <markus_sabadello> +0.5 Prefer the other one but I can live with this too.
19:26:40 <justin_r> -1 this conflates the purpose
19:26:41 <Orie> -1
19:26:44 <rhiaro> 0
19:26:44 <drummond> -1
19:26:45 <dlongley> -0
19:26:48 <brent> 0
19:26:48 <shigeya> +0.5
19:26:53 <jonathan_holt> 0, don't think it is at the same caliber as other core properties
19:26:56 <Eugeniu_Rusu> -0.5
19:26:57 <phila> -1 I think we agreed @context is not a property, no?
19:27:01 <tplooker> 0
19:27:02 <kristina> -1
19:27:06 <rhiaro> burn: evenly split, very nice
19:27:14 <Orie> my reason for -1, is that the spec is not easier to use with either of these changes...
19:27:18 <brent> q?
19:27:25 <selfissued_> As we discussed, @context is JSON-LD syntax - not a property
19:27:30 <manu> q-
19:27:58 <identitywoman_> identitywoman_ has joined #did
19:28:34 <drummond> PROPOSAL: 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”).
19:28:35 <rhiaro> drummond: having run those previous two, this proposal will be a simple way of looking at it
19:28:58 <selfissued_> q+
19:29:09 <by_caballero__juan_> by_caballero__juan_ has joined #did
19:29:11 <by_caballero__juan_> present+
19:29:29 <phila> q+
19:29:32 <burn> ack selfissued_
19:29:36 <rhiaro> drummond: @context appearing in json only or cddl or yaml would be ar epresentation-foreign property and we say here is what you do
19:29:41 <kristina> this is a good summary
19:29:49 <markus_sabadello> q+
19:29:52 <rhiaro> selfissued_: I can't live with that wording because @context is jsonld syntax, it's not a property
19:30:06 <rhiaro> ... it's a reference to context files that lists properties but it's not a property in of itself
19:30:08 <manu> q+ to request that we do something simple.
19:30:11 <rhiaro> drummond: representation specific syntax?
19:30:12 <Orie> mike... its a property if a JSON object.
19:30:21 <rhiaro> selfissued_: that's fine as long as it lives in the jsonld section and not the abstract data model section
19:30:24 <Orie> how can you possibly not see that?
19:30:25 <rhiaro> ... it can define whatever syntax it wants
19:30:36 <jonathan_holt> I found Carsten's comment helpful from our thread discussing this: https://github.com/w3c/did-spec-registries/pull/138#issuecomment-721624293
19:30:38 <burn> q?
19:30:40 <rhiaro> drummond: the thing that gets tricky is when it gets.. i'll update it
19:31:05 <drummond> 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 they appear in a representation other than the one in which they are defined (“representation-foreign syntax”).
19:31:05 <rhiaro> selfissued_: the core problem here is we're considering a layering violation, calling somethins 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
19:31:06 <burn> ack phila
19:31:11 <rhiaro> phila: I agree @context isn't a property
19:31:17 <rhiaro> ... drummond's proposal is a lot closer to what's in my head
19:31:22 <rhiaro> ... sorry I've been absent this week
19:31:31 <rhiaro> ... my words are a long way from well informed
19:31:41 <rhiaro> ... i have heard conversation today around content negotiation and the potential value of that
19:31:49 <rhiaro> ... ther ewas work done in another working group around content negotiation by profile
19:32:01 <rhiaro> ... this is not directly relevent but yow ould ask a server, I don't just want json I want json according this schema
19:32:11 <rhiaro> ... which would be an additional dimension for content negotiation
19:32:26 <rhiaro> ... the other thing i havne' hteard people talk about is that jsonld 1.1 allows you to include an http link header that says here's my context file
19:32:38 <rhiaro> ... in our work on resolving gs1 identifiers the payload that comes back is usually json but ther's a header with the context file
19:32:44 <rhiaro> ... @context does not appear in the json
19:32:47 <rhiaro> ... you have to get it from an extra thing
19:32:57 <burn> ack markus_sabadello
19:32:58 <rhiaro> ... that completely divorces th econtext from the json payload, might get the group out of this hole
19:33:11 <rhiaro> markus_sabadello: to resond to drummonds proposal
19:33:15 <rhiaro> ... I would support this proposal
19:33:31 <drummond> 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”)."
19:33:35 <rhiaro> ... 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
19:33:42 <rhiaro> ... still calls it a property which aligns with some people, but does differentiate
19:33:46 <rhiaro> ... i would support this compromise
19:34:06 <rhiaro> burn: this is not about what we would prefer is ideal or theoretically fabulous, but what you can accomplish
19:34:16 <rhiaro> ... if property term bugs you you can think of it as metadata thing in a key value representation
19:34:19 <burn> ack manu
19:34:19 <Zakim> manu, you wanted to request that we do something simple.
19:34:20 <drummond> q+
19:34:21 <rhiaro> ... let's not get too hung up on a word yet
19:34:28 <rhiaro> manu: I'm afraid that we're overengineering at thi spoint
19:34:33 <rhiaro> ... this is making it way more complex than what's necessary
19:34:44 <rhiaro> ... this decision, if we pick it up, I can hold my nose and do it, the decision will not change anything about an implementation
19:34:47 <brent> +1 to Manu
19:34:58 <rhiaro> ... 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
19:35:03 <rhiaro> ... and it's not going to change anything
19:35:08 <selfissued_> Good point @manu that resolutions that don't change implementations are less than helpful
19:35:12 <jonathan_holt> q+
19:35:20 <rhiaro> ... but as one of the people that has to do the editorial work it's going ot result in a spec that's more complicated and doens't work differently than if we were to put everything in one bucket
19:35:27 <rhiaro> ... that said, i'll hold my nose and not stand in the way of the proposal
19:35:47 <rhiaro> burn: write either proposal in a way that would get better consensus
19:36:03 <rhiaro> manu: run the proposal.. drummond's
19:36:10 <burn> ack drummond
19:36:26 <rhiaro> drummond: I've been trying to update it to incorporate mike's point about not calling it property
19:36:40 <rhiaro> ... 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
19:37:13 <rhiaro> ... I do get manu's point about making it look like two buckets but what we have been calling properties but we'v espent 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
19:37:15 <drummond> 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”).
19:37:19 <ivan> +1 to drummond on making it worth it
19:37:20 <burn> ack jonathan_holt
19:37:22 <Orie> +1
19:38:08 <drummond> Hmm. "Core Properties" and "Representation Properties" <== I could live with that
19:38:15 <rhiaro> 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 jsonld and json with an @context that we don't know
19:38:15 <rhiaro>  what to do with
19:38:21 <burn> 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”).
19:38:25 <Orie> +1
19:38:26 <manu> +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
19:38:26 <drummond> +1
19:38:28 <markus_sabadello> +0.5 I'd prefer not calling @context a property, but this is better than what we have now
19:38:30 <ivan> +1
19:38:33 <shigeya> +1
19:38:35 <phila> +1
19:38:35 <dlongley> 0
19:38:38 <rhiaro> 0
19:38:38 <selfissued_> -1 Over-engineered
19:38:39 <brent> 0
19:38:41 <justin_r> +1 (but bikeshed the specific names later)
19:38:42 <dmitriz> 0
19:38:44 <tplooker> 0
19:38:46 <kristina> 0
19:38:56 <drummond> Happy to bikeshed the names later
19:38:57 <Eugeniu_Rusu> +0.5 Agree with Markus
19:39:00 <rhiaro> burn: more support than anything else
19:39:16 <rhiaro> ... what i'm hearing from people who say it's overengineered,e ach one of them disagrees violently on which of the two alternatives to take
19:39:29 <rhiaro> ... it may be overengineering. Remember ugly baby?
19:39:35 <jonathan_holt> 0, I think this could work for my expanded document form of JSON-LD with @context removed
19:39:39 <rhiaro> ... w'ere trying to make sure we can accomplish the use cases
19:39:44 <rhiaro> ... making it elegant is not the requirement right now
19:39:53 <rhiaro> ... mike you gave a -1 on this
19:40:03 <rhiaro> ... aside from disliking the overengineering is this something you are unable to live with
19:40:17 <manu> q+ to ask if both Core Properties and Representation Properties are processed in the same way?
19:40:19 <rhiaro> selfissued_: it could be improved by not muddying the properties and syntax into the same bucket
19:40:26 <justin_r> .... but this is creating separate buckets??
19:40:32 <rhiaro> ... this is possibly some progress but we're going to have to come back and refine it again
19:40:38 <rhiaro> ... so that syntax is not called a property
19:40:42 <tplooker> Yeah thats my question?
19:40:43 <burn> q?
19:40:47 <rhiaro> dmitriz: this proposal does not bundle them together it separates them
19:40:56 <tplooker> I thought you were saying the seperate buckets was over-engineering?
19:41:03 <rhiaro> burn: he's objecting to the use of the word property for @context no matter what we put before th word property
19:41:28 <rhiaro> selfissued_: as long as @property is in the representation specific syntax bucket but that's not what was said
19:41:33 <rhiaro> justin_r: that is why we're creating this bucket
19:41:34 <markus_sabadello> q+
19:41:34 <burn> q?
19:41:35 <brent> we have to make the buckets before we put things in them
19:41:37 <rhiaro> ... we do need to bikeshed the names but not now
19:41:42 <rhiaro> drummond: i'm in favour of bikeshedding the names
19:41:47 <rhiaro> ... the point is the two buckets
19:41:57 <rhiaro> burn: mike i heard you say that this would be okay but we'd have to refine into more detail
19:42:10 <burn> RESOLVED: 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”).
19:42:16 <rhiaro> ... this doesn't mean there isn't more to do
19:42:19 <burn> ack manu
19:42:19 <Zakim> manu, you wanted to ask if both Core Properties and Representation Properties are processed in the same way?
19:42:19 <rhiaro> selfissued_: I'm fine with that
19:42:22 <drummond> Thanks Mike.
19:42:33 <rhiaro> manu: my assumption there was that things in both buckets are treated the exact same
19:42:34 <ivan> q+
19:42:50 <drummond> q+
19:42:52 <rhiaro> ... there will be no language in the spec that treats @context differently from unknown property 'foo' differently from known property 'authentication'
19:42:56 <burn> ack markus_sabadello
19:42:57 <rhiaro> ... they're all going to be treated the same
19:43:09 <rhiaro> markus_sabadello: I'm not sure about that
19:43:10 <justin_r> q+
19:43:12 <rhiaro> ... if they'd be all treated the same
19:43:39 <burn> ack ivan
19:43:39 <rhiaro> ... i think the assumption is @context would be in the bucket of the representation specific, where service or verificationmethod would be representation independent
19:43:48 <rhiaro> ivan: what manu is asking the asnwer is yes and no
19:44:15 <rhiaro> ... 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
19:44:25 <rhiaro> ... other ones are defined and to be used only by the specific syntax or representation
19:44:29 <markus_sabadello> +1 to ivan, that's exactly the difference
19:44:31 <rhiaro> ... and all the other rperesentations will ignore them
19:44:36 <rhiaro> ... that's the difference for me
19:44:39 <drummond> Ivan nails it
19:44:41 <justin_r> +1 to ivan, that's what I was going to point out
19:44:42 <burn> Personally, +1 to ivan
19:44:42 <justin_r> q-
19:44:46 <rhiaro> ... that is true that a json implementation will do the same as it does today
19:44:50 <rhiaro> ... jsonld will do the same as today
19:44:53 <manu> That would be fine with me, as long as no one in the group disagrees.
19:45:00 <rhiaro> ... this differentiation to understand what is going on in the spec is important, and that's the main difference
19:45:12 <rhiaro> burn: ther'es some agreement showing up here
19:45:25 <burn> ack drummond
19:45:28 <rhiaro> drummond: ivan nailed it, that's exactly why the two buckets
19:45:28 <manu> q+
19:45:41 <manu> q+ to note the concern I have is everyone getting a good feeling about us agreeing and not nailing this down.
19:45:52 <rhiaro> ... 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-independant property
19:45:56 <rhiaro> ... but not to discriminate, but to be clear
19:46:00 <burn> ack manu
19:46:00 <Zakim> manu, you wanted to note the concern I have is everyone getting a good feeling about us agreeing and not nailing this down.
19:46:26 <rhiaro> manu: 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
19:46:28 <dlongley> 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
19:46:30 <rhiaro> ... I'd like to see a proposal
19:46:34 <rhiaro> ... the goal here is to get the spec done
19:46:36 <rhiaro> ... and not to kick the can
19:46:42 <drummond> I like Justin's proposal
19:46:44 <rhiaro> ... and deal with it in a pr later which will inevitably get -1s
19:46:49 <rhiaro> ivan: i agree with the text that justin put there
19:46:52 <selfissued_> Justin's proposal is a positive step forward
19:47:04 <justin_r> PROPOSAL: representation-independent properties are processed the same regardless of representation, representation-specific syntax is potentially treated differently depending on the representation.
19:47:12 <manu> -1, not specific enough
19:47:12 <drummond> +1
19:47:12 <ivan> +1
19:47:13 <selfissued_> +1
19:47:13 <Eugeniu_Rusu> +1
19:47:14 <kristina> +1
19:47:14 <phila> +1
19:47:14 <justin_r> +1
19:47:15 <markus_sabadello> +1
19:47:17 <brent> +1
19:47:18 <Orie> +1
19:47:19 <shigeya> +1
19:47:21 <tplooker> +1
19:47:24 <justin_r> q+ to answer manu
19:47:25 <dlongley> +1 and we shuold say how
19:47:33 <jonathan_holt> +1 seems fair statement
19:47:34 <ivan> q+
19:47:36 <rhiaro> +1 with notes for representation-specific properties
19:47:43 <tplooker> provided we qualify what different means
19:47:52 <rhiaro> burn: manu wants to knwo the statement about potentially treated differently, you want to know how
19:47:58 <rhiaro> ... I think what others are saying you get to define that
19:48:00 <burn> ack justin_r
19:48:00 <Zakim> justin_r, you wanted to answer manu
19:48:02 <rhiaro> justin_r: you get to define that.
19:48:06 <manu> q+ the problem is who gets to define what?
19:48:08 <drummond> I think we already answered that this morning
19:48:14 <manu> q+ to note the problem is who gets to define what?
19:48:17 <Orie> q+
19:48:26 <rhiaro> ... 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
19:48:34 <rhiaro> ... and therefore they get to decide what to do with them
19:48:36 <rhiaro> ... in that process
19:48:47 <dlongley> 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
19:48:59 <rhiaro> ... if it is not a representaton syntax that you're representation deals with you treat it as an unknown property and chuck it through like we talked about earlier
19:49:05 <rhiaro> manu: good please put that in the proposal
19:49:08 <justin_r> PROPOSAL: 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
19:49:13 <burn> ack ivan
19:49:24 <rhiaro> ivan: I think it was said... it ties back to what we discussed before *my* dinner
19:49:42 <rhiaro> ... 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 thereofre I will ignore it
19:49:45 <rhiaro> ... this is exactly how it maps
19:49:58 <drummond> +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.
19:49:59 <rhiaro> ... makes the decision we made earlier today put in the right context (pun intended)
19:50:00 <burn> ack manu
19:50:00 <Zakim> manu, you wanted to note the problem is who gets to define what?
19:50:12 <drummond> q+
19:50:14 <rhiaro> manu: we need to be clear who is defining what
19:50:35 <rhiaro> ... 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
19:50:43 <rhiaro> ivan: the json only representation @context is not in its bucket
19:50:45 <rhiaro> ... and it will ignore it
19:50:48 <rhiaro> ... that is what this said
19:50:53 <rhiaro> manu: that's fine, i want to make sure everyone agrees
19:51:02 <rhiaro> ... we started this hour off with markus disagreeing, I want to make sure everyone is on board
19:51:08 <rhiaro> ... trying to make sure we all really agree to this stuff
19:51:25 <rhiaro> ... 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
19:51:33 <burn> ack Orie
19:51:40 <rhiaro> Orie: i agree with what manu saying
19:51:47 <rhiaro> ... the people are saying "you get to deicde" and not defining "you"
19:51:53 <rhiaro> ... my proposal is the did method producing a representation gets to decide
19:52:05 <burn> q?
19:52:07 <rhiaro> ... I believe if someone i smaking a decision about what goes in a concrete representation and it's not the DID method we're doing something wrong her
19:52:07 <selfissued_> q+
19:52:10 <rhiaro> s/her/here
19:52:12 <ivan> +1 to dlongley (and brent, which is very close)
19:52:14 <burn> ack drummond
19:52:30 <burn> ack selfissued_
19:52:31 <rhiaro> drummond: I'd like to see dave longley's proposal run
19:52:48 <rhiaro> selfissued_: I'm responding to DID methods should define this stuff... in most cases the spec test about the representation should define this stuff
19:52:52 <drummond> My proposal will address Mike's point
19:52:55 <justin_r> +1 this is defined by the representation definition
19:52:59 <jonathan_holt> not a property, not a representation syntax, but a semantic coercion type
19:53:00 <burn> q?
19:53:01 <rhiaro> ... and method sshould follow what the spec text about a representation say
19:53:07 <justin_r> (which is what dlongley is saying I think)
19:53:30 <rhiaro> burn: who decides is the crux - the did method or the representation definition in the spec?
19:53:35 <markus_sabadello> q+
19:53:45 <dlongley> PROPOSAL: 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.
19:53:54 <selfissued_> +1
19:53:55 <justin_r> +1 it's fine
19:53:55 <dlongley> +1
19:53:55 <drummond> +1
19:53:56 <manu> +1
19:53:56 <Eugeniu_Rusu> +1
19:53:58 <rhiaro> +1
19:53:59 <kristina> +1
19:53:59 <brent> +1
19:54:01 <shigeya> +1
19:54:02 <Orie> +1
19:54:05 <dmitriz> +1
19:54:06 <ivan> +1
19:54:09 <tplooker> +1
19:54:23 <markus_sabadello> -0.5
19:54:23 <phila> 0
19:54:28 <jonathan_holt> 0, seems reasonable
19:54:53 <rhiaro> burn: now... markus! we've gone to -0.5 to -1
19:55:03 <rhiaro> markus_sabadello: I don't understand the last part, representation specific syntax is passed through the ADM
19:55:37 <rhiaro> dlongley: what i ment by that is when youare 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 fo rwhich that syntax is native it can be used
19:55:47 <rhiaro> markus_sabadello: also means syntax specific to one representation would end up in others
19:55:51 <rhiaro> drummond: only if you ask for it
19:55:53 <rhiaro> markus_sabadello: okay..
19:56:07 <rhiaro> burn: explain only if you ask for it
19:56:18 <phila> q+
19:56:23 <rhiaro> dlongley: you're doing a translation from something that you have to some other representation. when it is present there that's asking for it
19:56:31 <jonathan_holt> seems like my MIME accept proposal
19:56:38 <burn> ack markus_sabadello
19:56:46 <burn> ack phila
19:57:16 <rhiaro> phila: the reason I put a 0 for that is becuase I was concerned that it seems very gung ho to say if there's soemthing you don't udnerstand you should skip it. Often that is okay. but what i heard mike say is the @context thing mucks up a json thing (I've heard that before elsewhere)
19:57:28 <dmitriz> q+
19:57:30 <rhiaro> ... blandly saying if you don't understand it ignore it itmight screw things up in your processor designed to do one thing and you give it something else and it balks
19:57:35 <markus_sabadello> q+
19:57:40 <rhiaro> ... it's a nice idea, good idea, support the aspiration, worried about in practice
19:57:47 <dmitriz> q-
19:57:48 <rhiaro> burn: we came to a resolution specifically on that point that I do not want to renegotiate
19:57:50 <rhiaro> phila: sorry
19:57:57 <burn> q?
19:58:00 <burn> ack markus_sabadello
19:58:02 <rhiaro> burn: the real question is whether dave was saying something differnet or additional from what we deicded earlier
19:58:26 <rhiaro> 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
19:58:33 <rhiaro> ... means @context in a yaml file, xml namespaces in a json file and so on
19:58:33 <dmitriz> +1 re manu's phrasing "is available to the processor"
19:58:38 <rhiaro> ... I wouldn't like to see that but I can live with that
19:59:02 <drummond> q?
19:59:03 <burn> RESOLVED: 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.
19:59:18 <rhiaro> burn: thank you thank you thank you thank you
19:59:24 <drummond> I have one more proposal that would give us even further clarification
19:59:30 <rhiaro> ... I share manu's concern when things go to Prs but this is more precise
19:59:37 <rhiaro> ... we are at the end of our session time
19:59:41 <rhiaro> ... which is also a miracle
19:59:45 <rhiaro> ... we need to switch to something else
19:59:48 <rhiaro> ... thank you again, I mean it
19:59:53 <rhiaro> ... let's see if we can move forward with it
20:00:06 <ivan> q+
20:00:08 <rhiaro> ... 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
20:00:18 <rhiaro> ... because as manu says hopefully this doesn't get killed when it becomes a PR
20:00:27 <rhiaro> ... make sure that your points were covered but don't introduce new sticking points if you don't have to
20:00:28 <burn> ack ivan
20:00:49 <rhiaro> ivan: 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
20:00:59 <rhiaro> ... there is such a network maze of different PRs that I am lost
20:01:01 <manu> q+
20:01:04 <burn> ack manu
20:01:18 <rhiaro> manu: 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
20:01:28 <rhiaro> ... I did look at how many issues are affected by the ADM, not even the editors agree
20:01:35 <rhiaro> ... let's push that off for now, let's get the PRs in
20:01:47 <rhiaro> ... 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
20:02:01 <rhiaro> burn: my suggestion is that dave would leave that because he made the proposal
20:02:06 <dmitriz> p
20:02:15 <rhiaro> ... mental shift now, take a deep breath
20:02:34 <rhiaro> Topic: Other work items
20:02:45 <Orie_> Orie_ has joined #did
20:02:45 <manu> scribe+
20:03:02 <phila> https://w3c.github.io/did-use-cases/#actions
20:03:07 <manu> phila: Going to focus on one thing
20:03:13 <manu> phila: new pictures... check out the link above.
20:03:37 <manu> phila: some concerns -- division between Actions wasn't clear
20:04:08 <drummond> I like these very much!
20:04:14 <manu> phila: 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.
20:04:18 <manu> phila: We have a number of PRs that are ready to go -- we're close!
20:04:24 <manu> phila: No new use cases!
20:04:43 <manu> phila: Please let me stop.
20:04:53 <manu> phila: Help me stop... DRUMMOND.
20:05:13 <manu> burn: Do you need anything else from the group?
20:05:33 <manu> phila: 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.
20:05:39 <manu> phila: We want a conclusion.
20:05:46 <manu> burn: Any questions from the group?
20:05:49 <manu> None
20:05:53 <manu> burn: Thank you Phil.
20:06:20 <brent> q+ to ask if we're actually going to have one and who will take charge
20:06:28 <manu> Topic: Implementation Guide
20:06:29 <burn> ack brent
20:06:29 <Zakim> brent, you wanted to ask if we're actually going to have one and who will take charge
20:06:38 <drummond> q+
20:06:58 <manu> brent: 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.
20:07:07 <burn> ack drummond
20:07:11 <ivan> present+ danielhardman
20:07:11 <manu> brent: Until we can resolve those things, we can't assume we're going to have an Implementation Guide.
20:07:26 <manu> drummond: I know that I've been assigned, markus has been assigned, not putting up my hand - can't be primary driver.
20:07:40 <manu> drummond: I can be a contributor, but primary driver... that's not me.
20:07:51 <burn> q?
20:07:54 <manu> burn: Anyone else?
20:08:04 <manu> burn: If no one takes lead, it won't happen.
20:08:11 <drummond> I agree with Amy, and am very happy to help her
20:08:32 <manu> burn: Thank you to Amy and Drummond for volunteering to help -- Amy said she could volunteer but doesn't have content for it.
20:08:41 <manu> burn: Where that boundary is -- might be sufficient to get this done.
20:08:52 <manu> burn: Moving along...
20:08:54 <manu> Topic: Rubric
20:09:06 <burn> q?
20:09:20 <manu> dhardman: I've been working on this with Joe, if he's on -- he can speak, if not, can speak to it.
20:09:39 <manu> dhardman: Rubric wasn't making progress over summer, but once Aug/Sept hit, we were able to make progress.
20:10:34 <manu> dhardman: 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.
20:11:12 <manu> dhardman: 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?
20:11:55 <manu> dhardman: 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.
20:12:22 <manu> dhardman: Then they scored them, abbreviated example for matrix looks like for scoring on this slide.
20:12:44 <manu> dhardman: Letter grades, not intended to be grade metaphor, letters for scoring, three columsn are how does this method manifest in spec, network, etc.
20:13:25 <manu> dhardman: 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.
20:14:34 <manu> dhardman: 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
20:14:34 <manu> own method.
20:15:15 <manu> dhardman: 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.
20:15:40 <manu> dhardman: 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.
20:16:37 <manu> dhardman: Wanted to walk through new sections briefly -- in an hour or two, will have content I'mt alking to as PR against repo.
20:16:45 <drummond> This is awesome
20:16:55 <manu> dhardman: What we propose on security, went through comments, came up with 9 questions about cybersecurity related topics.
20:17:11 <manu> dhardman: Does a DID Method, how robust is crypto? Measure by bits of security...
20:17:37 <manu> dhardman: 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?
20:18:06 <manu> dhardman: Is security vetted by experts and battle hardened, or is it brand new? Little risky until furhter review? How friendly is method to future proofing?
20:18:27 <manu> dhardman: Are self-certifying identifiers provided... Protections against DoS, hacking, legal cease and desist?
20:18:32 <manu> dhardman: Provable DID Document history?
20:19:03 <manu> dhardman: Code for method is published, has vulnerability disclosure mechanism, diffuse control... M of N mechanisms - threshold signatures, whether it supports FIPS regimes, etc.
20:19:09 <wayne> q+
20:19:21 <justin_r> q+
20:19:30 <manu> dhardman: 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?
20:19:43 <ivan> see [slide on security](https://docs.google.com/presentation/d/1RoE8E4y8S1j65EJaXZ8oihkduNbjTXXvdwtkzw961Xw/edit#slide=id.g9f4c7913d4_149_15)
20:19:44 <burn> ack wayne
20:19:47 <manu> dhardman: Hopefully that seems like progress.
20:20:32 <manu> wayne: 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 --
20:20:44 <manu> wayne: "Reviweed by experts" -- very subjective...
20:21:03 <manu> wayne: A lot of these have huge potential to go to subjectivity, but overall like general direction for categories.
20:21:25 <manu> dhardman: The rubric is already subjective, not intended to provide definitive answers... designed to generate thought provoking questions.
20:21:37 <manu> dhardman: The work of this group is not to say "method A is good and method B is not"
20:21:51 <manu> dhardman: The goal is to tease out questions... but the more measurable is better.
20:21:58 <burn> ack justin_r
20:22:29 <manu> justin_r: 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.
20:22:54 <manu> justin_r: especially if some method is susceptible for algorithm substitution attack... "same algorithm from 2005", that seems that could be captured and measured here.
20:23:51 <manu> dhardman: 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.
20:24:38 <manu> dhardman: 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.
20:24:42 <ivan> See [slide on privacy](https://docs.google.com/presentation/d/1RoE8E4y8S1j65EJaXZ8oihkduNbjTXXvdwtkzw961Xw/edit#slide=id.g9f4c7913d4_149_22)
20:25:02 <manu> dhardman: Is there some way of inferring that DID A and DID B are both controlled by same person, could possibly be fingerprint risk.
20:25:35 <manu> dhardman: 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.
20:25:55 <manu> dhardman: Deletion -- possible to undo mistakes, how bad are mistakes if they can't be undone... how does right to be forgotten work?
20:26:21 <manu> dhardman: Type and danger -- serviceEndpoints -- does DID Method give technical/policy/explanatory safeguards to prevent privacy mistakes?
20:26:25 <ivan> q+
20:26:34 <manu> burn: Thank you so much, great review.
20:26:40 <drummond> Outstanding review, Daniel.
20:26:56 <manu> burn: 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.
20:27:14 <burn> ack ivan
20:28:05 <manu> ivan: We need section on security/privacy on 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.
20:28:47 <manu> burn: This has been a good but probably tiring 4 days to do this work, cancelling all of the DID WG meethings next week.
20:29:03 <manu> burn: We are doing a Virtual Face to Face Recovery Times.
20:29:29 <manu> burn: Any last words?
20:29:49 <manu> burn: We came to some good decisions, and not just feel good decisions.
20:30:02 <agropper> Well done organizers!
20:30:04 <ivan> q+
20:30:05 <brent> +1 thanks to everyone!
20:30:17 <manu> drummond: We got good things done, need to go through categorized issues.
20:30:39 <manu> ivan: I'll clean up meeting minutes tomorrow -- please go through them... verify.
20:31:02 <manu> burn: With that, thank you, officially done!
20:31:07 <kristina> breakfast
20:31:11 <kristina> 5am here
20:31:32 <dmitriz> @kristina, others from that timezone - that is intense! :)
20:31:32 <kristina> that was great thank you everyone!
20:31:43 <ivan> zakim, end meeting
20:31:43 <Zakim> As of this point the attendees have been burn, wayne, rhiaro, shigeya, justin_r, jonathan_holt, manu, brent, ivan, Eugeniu_Rusu, tplooker, dlongley, agropper, Tomoaki_Mizushima,
20:31:46 <Zakim> ... selfissued_, present+, JoeAndrieu, drummond, markus, dmitriz, phila, Orie, by_caballero__juan, identitywoman, by_caballero__juan_, danielhardman
20:31:46 <Zakim> RRSAgent, please draft minutes
20:31:46 <RRSAgent> I have made the request to generate https://www.w3.org/2020/11/05-did-minutes.html Zakim
20:31:48 <Zakim> I am happy to have been of service, ivan; please remember to excuse RRSAgent.  Goodbye
20:31:52 <Zakim> Zakim has left #did
20:32:01 <kristina> present+
20:32:40 <ivan> rrsagent, draft minutes
20:32:40 <RRSAgent> I have made the request to generate https://www.w3.org/2020/11/05-did-minutes.html ivan
20:35:18 <yuki> yuki has left #did
20:36:42 <ivan> rrsagent, bye
20:36:42 <RRSAgent> I see no action items