15:00:40 RRSAgent has joined #did 15:00:44 logging to https://www.w3.org/2024/11/20-did-irc 15:00:44 JoeAndrieu has joined #did 15:00:55 Zakim, start the meeting 15:00:55 RRSAgent, make logs Public 15:00:57 please title this meeting ("meeting: ..."), decentralgabe 15:00:58 present+ 15:00:59 KevinDean has joined #did 15:01:01 present+ 15:01:08 present+ 15:01:12 meeting: DID WG Special Topic Call Agenda 2024-11-20 https://lists.w3.org/Archives/Public/public-did-wg/2024Nov/0004.html 15:01:23 Wip has joined #did 15:01:26 markus_sabadello has joined #did 15:01:35 present+ 15:01:49 present+ 15:01:51 present+ 15:02:11 present+ 15:02:32 TallTed has joined #did 15:02:32 scribe+ 15:02:35 present+ 15:02:50 scribe+ 15:02:53 topic: https://github.com/w3c/did-core/issues/855 15:02:59 decentralgabe: The topic of today is issue 855, simplify abstract data model to be more concrete. 15:03:20 q+ 15:03:21 decentralgabe: Manu opened the issue, Joe has made some comments, invite either one of you to queue to speak to the issue and what you'd like to see happen in the group. 15:03:26 ack JoeAndrieu 15:04:14 bigbluehat has joined #did 15:04:19 JoeAndrieu: I made my case in the Github issue, the abstract data model is a bad idea (my opinion), some think it's a good idea. My biggest problem is that its untestable and was not tested in last iteration, avoided raising that last time, political difficulties was why we avoided the discussion. We have spec features that are not implemented, we need to fix that. 15:04:19 q+ 15:04:21 q+ 15:04:22 ack manu 15:04:34 present+ 15:04:50 manu: I agree that the abstract data model doesnt buy us much in this spec 15:04:53 danpape has joined #did 15:05:14 ... I agree we didnt push on it last iteration due to other challenges being worked through the group 15:05:35 q+ the feature is an ADM 15:05:36 ... I disagree that we have untestable features in the spec. Perhaps JoeAndrieu can point these out 15:05:41 present+ 15:05:52 ... One of the biggest problems is the amount of time that we as a group spend talking about it 15:06:00 q+ 15:06:23 ... As a spec editor I don;t know how much work it would take to remove the abstract data model. I am fairly confident it wouldn't affect implementations 15:06:33 ... Perhaps a signal that the abstract data model isnt buying us much 15:06:52 dmitriz has joined #did 15:07:15 ... Also noting that the controller document does not have an abstract data model. So it will be a little strange to use a base document with a concrete data model - the controller doc - then layer on an abstract data model 15:07:50 ... I think the biggest danger with removing the abstract data model, is to do with the amount of effort we put in to make the DID spec abstract. I think we did a good job here 15:08:27 ... removing the abstract data model will invite a couple of things. People will throw their hands up and say well DIDs are not for me. And go off an do DID like things elswhere 15:08:53 ... There may be knock on effects from this change that we will have to deal with. This could take 2-3 months of our time 15:09:05 q? 15:09:09 ... Also noting this could happen anyway due to the adoption of the controller doc 15:09:16 ... I am on the fence of the way forward 15:09:31 ack markus_sabadello 15:09:35 decentralgabe: I want to highlight point about practical DID adoption - focus groups time on impactful time on objectives. 15:09:49 q+ 15:10:16 JennieM has joined #did 15:10:21 present+ 15:10:49 markus_sabadello: I started with reason for abstract data model -- some wanted DID Documents in JSON-LD and plain JSON and that's obsolete already if we adopt controller document and I think we already had a resolution on one media type -- application/did -- both JSON and JSON-LD, interpretation would be the same whether there is a context, whether or not you use JSON-LD processor, interpretation is the same... with that, I'm thinking, why do we need an 15:10:49 abstract data model still? Doesn't that remove original rationale/reasoning? 15:10:56 ack ivan 15:12:01 ivan: I was one arguing for abstract data model, still believe in it, that being said, I think most important point at this time is the controller document work -- my understanding, the DID Document and data model is a controller document with some minor features. Probably it's a bit extreme, but most of DID Core spec related to DID Document would be removed form standard anyway, in a sense, controller document might have made this entire discussion moot by 15:12:01 now. 15:12:24 ack ChristopherA 15:12:25 decentralgabe: We might need more analysis on controller document impact? Is that a good next step? 15:13:10 q+ 15:13:33 ack bigbluehat 15:13:34 ChristopherA: I've been in favor of abstract model, in reality, it has now become a signal rather than a technical reality... there are a number of parties that will take removing it as a signal of 100% in on JSON-LD and that there are people will object to that, whether that's relevant or they're implementing DIDs, I don't know. Might cause us headaches. 15:13:35 q+ 15:13:45 bigbluehat: Verifiable Credentials does JSON and JSON-LD without an abstract data model. 15:13:50 ack manu 15:14:21 manu: responding to ChristopherA, the text in current controller doc is not JSONLD maximalist. It says we would like you to include a context, but does not require it 15:14:29 q+ 15:15:13 ... I have the same concerns as ChristopherA, people will twist this to their narrative that we are JSONLD only. When in fact we have gone the other way. @context is not required, but it is one way to signal to version of the spec you are using 15:15:53 ... What we want to say is that the semantics are the same between a JSONLD and JSON documents. If they are not this is a mistake. That is currently in the spec 15:16:17 ... I don;t think it has any implementation issues with removing the abstract data model 15:16:45 ... What we could do is say we are going to remove the abstract data model and see who raises their voices to challenge this direction 15:16:45 q+ 15:17:36 ... There may be statements that were helpful to us that we were getting ready to remove. We are not allowed to make class 4 changes. There might be arguments that this is a class 4 change. But I think we can work around it 15:18:01 ... We are lucky that the test suite tests against concrete instantiations of the data model. Getting rid of the ADM is not going to affect the test suite 15:18:52 q+ 15:18:53 ... We could do a pass to remove the abstract data model and see if doing that changes any normative changes. Then we could say we are doing this, point at what the new thing looks like and then wait for the reaction of the community 15:19:08 ack markus_sabadello 15:19:11 decentralgabe: A proposal to align DID Core with Controller Document to see what normative changes it might make and gauge reaction from community. 15:19:53 q+ to mention political pushback was based on a misunderstanding that JSON-LD is not JSON 15:20:06 q- 15:20:09 q+ 15:20:09 markus_sabadello: I'm not so worried about political reactions, @context is effectively optional, which was the original desire of people that just wanted to do plain JSON. They didn't say they wanted abstract data model, they didn't want abstract representations, they wanted @context to be optional, and that's what we have right now. Spec would be less complex, another benefit (people say it's complicated). I'm not that concerned about the reactions. 15:20:16 ack ivan 15:21:24 ack JoeAndrieu 15:21:24 JoeAndrieu, you wanted to mention political pushback was based on a misunderstanding that JSON-LD is not JSON 15:21:24 ivan: Yeah, I think I'll proposal something along the line of what Manu proposed: In view of controller document, and we decided to align, we can essentially declare the issue about abstract data model as moot -- no need to keep discussing, we will rely on controller document most of the time, whole thing will disappear without referring to it. It will just go away, automatically, we don't have to discuss it anymore, which creates energy loss. 15:21:59 JoeAndrieu: That's interesting Ivan, I like that thinking, I do think as we shift to controller document, it has a concrete representation, we have to extract between two... won't make sense to make controller document abstract. 15:22:30 q+ 15:22:40 ack ChristopherA 15:22:43 q+ 15:22:43 JoeAndrieu: One of the reasons I'm not too concerned w/ political fallout, based on misunderstanding on JSON-LD vs. JSON -- people thought they were two different things, we can have common representation that both world views can accept current state. 15:23:25 q+ to mention alternate formats 15:23:39 ChristopherA: If we had a non-CBOR-LD version of controller documents, boutique one, that we might show you can have other formats that we support. Don't see anyone on this call that is comitted to boutique CBOR representation, to demonstrate we're abstract instead of putting in the spec. 15:23:44 q+ on demonstrating CBOR 15:23:46 ack Wip 15:24:11 Wip: The controller document argument is compelling, but this group needs to pass a resolution to adopt it, I think we were waiting for it to go into next stage of W3C Process. 15:24:56 ack decentralgabe 15:24:58 Wip: What is our story around allowing alternate formats? CBOR, YAML, etc? I think thing there is same as VCDM, people have to define bidirectional map from their representation into JSON. There should be a pathway for people to implement DID Documents in whatever way they want. 15:25:13 decentralgabe: Chair hat off: Other representations, does it close the door on non-JSON representations, solved elsewhere? 15:25:14 ack JoeAndrieu 15:25:14 JoeAndrieu, you wanted to mention alternate formats 15:25:16 -> Issue on the reference to the Controller Document https://github.com/w3c/did-core/issues/854 15:26:34 JoeAndrieu: I think it makes it easier, in current pattern, what we have is other representations -- go back to abstract data model, you have to go to abstract data model, which they didn't do in the first place. What we want is to go between serializations, anything is valid as long as you go from X to DID Document, then people can compress it ... it's just not a DID Document (yet), as long as you have a transformation that can get you back to the 15:26:34 original, you're fine. 15:26:52 JoeAndrieu: If we start w/ abstract data model, it's more difficult, if we don't, it's easier to deal w/ alternate representations. 15:26:53 ack manu 15:26:53 manu, you wanted to comment on demonstrating CBOR 15:27:00 q+ 15:27:45 chair: Gabe Cohen 15:27:52 q+ 15:27:58 q- 15:28:04 manu: +1 to what JoeAndrieu & Wip said. We have language around being conformant with the DID document ecosystem. With bidirectional transformation rules. I agree with JoeAndrieu's point that without the ADM this is easier. As long as people can convert their representation into the DID doc representation you are golden. 15:28:14 q+ 15:28:26 ... for example in YAML it is very straightforward. There are many libraries that transform YAML into JSON. 15:29:02 ... If people want to do compression, they can do that. So long as you can get back to the original representation. You wouldnt have to worry about the abstract data model 15:29:06 q+ 15:29:22 ... hearing a lot of consensus 15:29:31 ... I did think we already passed a resolution about using the controller document. 15:29:44 -> Latest comment on the relationship to the CD https://github.com/w3c/did-core/issues/854#issuecomment-2332954287 15:30:14 ... It is stable enough that the editors could make an attempt to alight the DID core spec with the controller document and remove the ADM. Seeing if we run into any normative changes that are required 15:30:25 ... What do we think are the next steps 15:30:49 ack markus_sabadello 15:30:50 decentralgabe: We did pass resolution to align w/ controller document when we're ready. I'm good to not pass another one, just have Editor's do the work. If people feel that's not strong enough, we need a resolution, happy to run one if someone wants to draft the language. 15:30:53 q+ 15:31:35 markus_sabadello: I agree with Manu and Joe, one thing I was wondering, does it affect extension properties in any way? it's a good thing to do that, how would that change if we don't have abstract data model? Would we require people to register their extensions in our registry? Still optional? 15:31:36 q+ 15:31:42 ack burn 15:31:44 q+ to talk to registration of extensions 15:32:19 FYI I do not see a resolution about adopting the controller document here - https://www.w3.org/2024/list-resolutions/?g=did 15:32:33 burn: I added myself to queue before Manu -- this is basically an extended +1, about the direction we're talking about moving -- you had questioned this Markus, when I put first draft of spec into ReSpec, talked w/ Manu about this, abstract out specific syntax and try to create generic model and concrete realizations. 15:33:40 burn: That was for two reasons -- it was very clear there was going to be a battle around JSON vs. JSON-LD -- this is the Verifiable Credentials spec -- other reason, we did want to make it clear to people was say that what we were trying to define wasn't limited to specific syntax, used XML as an example -- we've gradually removed XML and other things. This conversation has convinced me, as Manu said, there is another way to address challenges for original 15:33:40 abstract data model was meant to address. 15:34:07 burn: As a proponent for the abstract data model (historically), I think arguments have been addressed correctly, we did same thing w/ DID spec because of what happened w/ VC spec, it's time to move on, thanks for all the great work! 15:34:09 q? 15:34:33 q+ 15:34:41 ack ChristopherA 15:35:21 s/abstract out/I abstracted out from the/ 15:36:11 -> Latest discussion in the group on the controller issue https://www.w3.org/2024/09/05-did-minutes.html#t04 15:36:20 q? 15:36:43 ChristopherA: General statements are: we can remove abstract syntax model if we do X, but then when I hear the list it includes things that are "oh, well it needs to be two way -- what does that mean?" Gordian can do elision and it will look just like a DID Document, conformant there, but Gordian-specific one that understands elision is a superset of capabilities and it isn't two way. One interpretation of two-way, along with this, we don't have to use 15:36:43 abstract syntax model, but we do need other points on what's going to replace that, better definition of what does round-trip really mean? It's not clear to me. 15:36:52 ack ivan 15:37:43 ivan: I did some digging, I put pointers to minutes, last time we discussed this in WG, they all go in same direction - we didn't have a formal resolution, good to have it, agreement of WG to wait until CR. 15:37:47 ack manu 15:37:47 manu, you wanted to talk to registration of extensions 15:38:12 s/abstract syntax model, but/... abstract syntax model, but/ 15:38:31 manu: ChristopherA asked a good question. Wondering if we can defer answering what we mean by two way map until we are able to make a editorial pass. 15:38:32 s/abstract data model was/... abstract data model was/ 15:38:58 s/original, you're fine/... original, you're fine/ 15:39:17 ... Would like us to pass a proposal around the general direction and let the editors discover any issues that arise from this. We want to make Gordian work with DIDs, but we need to figure out how to do this. 15:40:03 ... With respect to markus's registration question. I think this is the same thing. We want extensions to be able to happen, and do not want to make drastic changes. But concerned that trying to solve these now will derail us. Would prefer to get started with the work and let that teach us 15:40:06 I have made the request to generate https://www.w3.org/2024/11/20-did-minutes.html TallTed 15:40:31 ... decentralgabe with respect to your proposal, lets leave out until CR. What is left on the controller document is largely editorial. Would like to start sooner than later on this 15:41:10 s/abstract data model still?/... abstract data model still?/ 15:41:12 decentralgabe: Ok, I've updated the proposal, we need to figure out two-way transformations, other representations, and how extensions are managed. I would like to see the group agree to try to address these after, open to hear what everyone thinks. 15:41:13 ack JoeAndrieu 15:41:14 q+ 15:41:31 s/don;t think/don't think/ 15:42:01 JoeAndrieu: I had proposed something incomplete, we don't control the controller document, we can't remove abstract data model from controller document -- a wrinkle -- proposal from Gabe is good, didn't have it depend on CR. I would also like to get into resolution on concrete representation for DID Document. 15:42:26 decentralgabe: Maybe we can split into two resolutions? 15:42:31 JoeAndrieu: I'm ok with two resolutions. 15:42:38 decentralgabe: will run proposal after Markus. 15:42:41 ack markus_sabadello 15:42:42 I have made the request to generate https://www.w3.org/2024/11/20-did-minutes.html TallTed 15:42:55 markus_sabadello: I agree with dealing w/ technical details after running resolution. 15:42:56 PROPOSAL: Align DID Core with the Controller Document specification (https://www.w3.org/TR/controller-document/), and attempt to remove language around the Abstract Data Model. 15:43:00 manu: +1 15:43:03 +1 15:43:03 +1 15:43:03 +1 15:43:05 +1 15:43:06 +1 15:43:17 +1 15:43:18 +1 15:43:21 +1 15:43:21 +1 15:43:24 +1 15:43:32 +0 15:43:40 (pending other proposal) 15:43:46 RESOLVED: Align DID Core with the Controller Document specification (https://www.w3.org/TR/controller-document/), and attempt to remove language around the Abstract Data Model. 15:44:29 reshare draft? 15:44:42 q+ 15:44:42 decentralgabe: ok, on to the second proposal from Joe. 15:44:47 ack ChristopherA 15:45:22 ChristopherA: Is this the one where we can put in bidirectional transformation and interpretation of concrete representation, maybe? Extension and intent to support other formats. That's not in this proposal. 15:45:24 q+ 15:45:30 ack manu 15:45:54 JoeAndrieu: I'll try to wordsmith the proposal. 15:46:27 q+ 15:46:39 ack manu 15:46:40 q+ 15:47:01 manu: I think we need to be more specific. The controller document is very clear about it being JSON. The DID document should be just as clear 15:47:14 q- 15:47:23 +1 to manu. We have to be aligned with the CD 15:47:43 I suggest avoiding the word "serialization" and instead use "representation" or "syntax" 15:48:01 ... THis doesnt mean that it is the only representation. It is totally okay to have a CBOR representation. There are multiple levels. One is there is a JSON representation, if it follows all the rules you are good to go. The other is if you can get whatever representation you want into the concrete JSON representation then you are good to go 15:48:22 ... I an hesitant about getting that language into this proposal 15:48:49 ... Lets leave the bidirectional language out of it for now 15:49:15 ... Then we wait to see if people in the community have issues with that. 15:49:27 brent has joined #did 15:49:47 good for me 15:49:57 q+ 15:49:58 decentralgabe: Let's say we allow alternative representations and come up with that language later. 15:50:02 ack markus_sabadello 15:50:13 q+ 15:50:17 markus_sabadello: Probably missing something, why do we need to profile this, why is this not part of profile document that we reference? 15:50:18 ack JoeAndrieu 15:50:27 JoeAndrieu: We don't control the controller document, we don't know what it'll end up as. 15:50:55 q+ 15:51:07 markus_sabadello: We reference it, we will use it, profile it in a way -- why would profile have anything w/ representation -- JSON vs. JSON-LD? Controller document, how to use context, etc. 15:51:08 q+ 15:51:14 q+ to note it has to do w/ media type. 15:51:35 ack JoeAndrieu 15:52:18 JoeAndrieu: language i"m trying to get in -- expect other specs to profile controller document, serialization migth be something we don't like. I don't think it'll go in that direction, but if we're dependent on that gorup, we have to profile it anyway, we have things in DID Core that have to do w/ that document. 15:52:32 JoeAndrieu: If controller document changes, we would have to undo that in our profiling. 15:52:34 ack manu 15:52:34 manu, you wanted to note it has to do w/ media type. 15:52:43 s/migth/might 15:53:15 manu: I agree with JoeAndrieu. We dont currently specify a media type in the controller document. This has to do with media types. The DID spec will have a different media type to the controller document 15:53:39 ... I dont think it hurts to include this in the proposal 15:53:54 decentralgabe: Does that clarify, Markus? Ok with language? 15:54:03 markus_sabadello: Sure, don't fully understand but not against, please run the proposal. 15:54:11 PROPOSAL: When profiling the Controller Document for the DID Document specification we will use JSON as a concrete representation, with language describing options for alternative representations. 15:54:19 +1 15:54:20 +1 15:54:22 +1 15:54:22 +1 15:54:23 +0.5 15:54:28 +1 (and revises my previous +0 to +1) 15:54:28 +1 15:54:29 +1 15:54:35 +1 15:54:39 +1 15:54:41 +1 15:54:55 RESOLVED: When profiling the Controller Document for the DID Document specification we will use JSON as a concrete representation, with language describing options for alternative representations. 15:55:00 decentralgabe: We need to ensure controller document has media type, we'll have to raise that issue over there. 15:55:14 q? 15:55:22 Ciao! 15:55:43 zakim, end the meeting 15:55:43 As of this point the attendees have been ivan, KevinDean, manu, Wip, JoeAndrieu, ChristopherA, markus_sabadello, pchampin, bigbluehat, danpape, JennieM 15:55:46 RRSAgent, please draft minutes 15:55:47 I have made the request to generate https://www.w3.org/2024/11/20-did-minutes.html Zakim 15:55:53 I am happy to have been of service, decentralgabe; please remember to excuse RRSAgent. Goodbye 15:55:53 Zakim has left #did 15:56:17 m2gbot, link issues with transcript 15:56:18 comment created: https://github.com/w3c/did-core/issues/855#issuecomment-2488962814 15:57:44 brent has joined #did 16:02:03 Wip has left #did 16:12:43 present+ 16:12:49 I have made the request to generate https://www.w3.org/2024/11/20-did-minutes.html TallTed 17:30:32 brent has joined #did 18:28:09 brent has joined #did 20:28:26 brent has joined #did 22:40:04 brent has joined #did