13:48:56 RRSAgent has joined #vcwg 13:49:00 logging to https://www.w3.org/2023/02/16-vcwg-irc 13:49:00 RRSAgent, make logs Public 13:49:01 please title this meeting ("meeting: ..."), ivan 13:49:13 Meeting: Verifiable Credentials Working Group F2F, 3rd day 13:49:13 Date: 2023-02-16 13:49:13 Agenda: https://docs.google.com/presentation/d/128DHWSzVxPgAhB0mq-h23_iATnbVeA4Y-JhNLjpcXJE/edit#slide=id.g2061a1a64f4_0_51 13:49:13 chair: kristina, brent 13:49:13 ivan has changed the topic to: Meeting Agenda 2023-02-16: https://docs.google.com/presentation/d/128DHWSzVxPgAhB0mq-h23_iATnbVeA4Y-JhNLjpcXJE/edit#slide=id.g2061a1a64f4_0_51 13:51:51 TallTed has joined #vcwg 13:54:23 decentralgabe has joined #vcwg 13:55:38 tzviya has joined #vcwg 13:57:12 Phil_ASU has joined #vcwg 13:57:20 Present+ 13:58:22 present+ 13:58:33 ChristopherA has joined #vcwg 13:58:45 present+ 13:59:21 present+ 13:59:30 present+ markus 13:59:45 present+ identitywoman 13:59:58 present+ dmitriz 14:01:01 present+ campbell 14:01:01 present+ dlongley 14:02:04 present+ 14:02:19 for folks not in Miami - seems like we'll have a late start today. only 4 of us here so far 14:04:05 Well, we west-coasters got up ;-) 14:04:22 present+ andres 14:04:44 GeunHyung_Kim has joined #vcwg 14:04:49 present+ 14:05:15 Paul_Dietrich_GS1 has joined #vcwg 14:05:15 booze cruises will do that... 14:07:49 manu_ has joined #vcwg 14:08:20 BC has joined #vcwg 14:08:36 Identitywoman has joined #vcwg 14:09:28 present+ 14:10:22 dmitriz has joined #vcwg 14:10:29 present+ 14:11:19 mprorock has joined #vcwg 14:12:31 zakim, who is here? 14:12:31 Present: Phil_ASU, TallTed, ChristopherA, ivan, markus, identitywoman, dmitriz, campbell, dlongley, decentralgabe, andres, GeunHyung_Kim, manu_ 14:12:33 On IRC I see mprorock, dmitriz, Identitywoman, BC, manu_, Paul_Dietrich_GS1, GeunHyung_Kim, ChristopherA, Phil_ASU, tzviya, decentralgabe, TallTed, RRSAgent, Zakim, ivan, dlongley, 14:12:33 ... cel, saysaywhat, csarven, shigeya, hadleybeeman, bigbluehat, Dongwoo, stonematt, dlehn, npd, w3c_modbot, stenr_, cel[h], ounfacdo, manu, bumblefudge, cel[m], rhiaro 14:13:08 samsmith has joined #vcwg 14:13:13 present+ 14:13:17 zakim, pick a victim 14:13:18 Not knowing who is chairing or who scribed recently, I propose campbell 14:13:19 brent has joined #vcwg 14:13:46 present+ 14:14:01 Will has joined #vcwg 14:14:04 present+ 14:14:20 Phil_F has joined #vcwg 14:14:22 Present+ 14:14:43 kristina has joined #vcwg 14:14:46 mkhraisha has joined #vcwg 14:14:52 dwaite has joined #vcwg 14:14:58 present+ 14:15:01 present+ kristina, orie, selfissued 14:15:23 present+ 14:15:28 present+ 14:15:45 selfissued has joined #vcwg 14:15:53 present+ 14:16:02 present+ 14:16:24 Orie has joined #vcwg 14:16:25 JoeAndrieu has joined #vcwg 14:16:30 andres has joined #vcwg 14:16:35 present+ 14:16:39 present+ 14:16:40 present+ 14:17:02 markus_sabadello has joined #vcwg 14:17:16 scribe+ 14:17:38 present+ 14:18:00 oliver has joined #vcwg 14:18:04 present+ oliver 14:18:10 brentz: welcome, thanks for joining, day 3 f2f meetings, meetings fantastic so far, excellent job on coming together. 14:18:43 ... main topic is @context and wether we should make it optional, after lunch is an off record conversation on industry affairs 14:19:13 ... immediately after lunch is use cases then gossip session. time at end of day is issue triage. 14:19:48 ... budget 30 min to airport atleast 14:19:49 Topic: `@context` optional or not 14:20:07 manjaroi3 has joined #vcwg 14:20:10 slide set starting at https://docs.google.com/presentation/d/128DHWSzVxPgAhB0mq-h23_iATnbVeA4Y-JhNLjpcXJE/edit#slide=id.g208ba739a3c_1_437 14:20:38 Gabe: this should be a friendly conversation 14:20:52 ... 30+ participants and 127 days, and 290 comments! 14:21:12 ... is the VCDM a JSON-LD data model? if yes keep @context otherwise make it optional. 14:21:24 ... second question is what type of interop are we supporting? 14:21:27 q? 14:21:40 ... last question does the future of VCs look brighter if we compromise? 14:22:13 ... hard to summarize, we've had special topic calls and months of discussion. There have been a few concrete proposals which we'll walk through. 14:22:47 ... on slides are some arguments for removing context, we don't want to mandate interop but rather enable it. JSONLD has a lot of footguns and we should provide a way to not do that. 14:23:10 ... a lot of the market has moved to non-ld credentials and we should recognize that, and lets think of other representations. 14:24:03 ... arguments for keeping status quo. not ideal for inteorp, well need registries, versioning is an important thing if we make @context optional. @vocab being in the base context means you can just ignore hte context property 14:24:37 q? 14:24:37 ... there is a large burden on implementers and verifiers, fewer options make it easier to adopt. extensibility is tricky 14:24:38 q+ to propose compact terminology (still a VC, but possibly a subset of features, but has all required terms/fields - still a context, but may not be embedded in the doc, identified and implied by a discrete media type) 14:24:43 ack mprorock 14:24:43 mprorock, you wanted to propose compact terminology (still a VC, but possibly a subset of features, but has all required terms/fields - still a context, but may not be embedded in 14:24:47 ... the doc, identified and implied by a discrete media type) 14:25:00 q+ 14:25:03 q+ 14:25:25 mprorock: noting from yesterday, we discussed that vc jwts are a different thing, weve had this notion of a compact credential, where it is still a vc that has an implied context that is identified via the media type. 14:25:42 q+ to talk about definitions 14:25:49 ... the interesting case is going to the compact form from the non-compact one, and is that desireable 14:26:01 s/vc jwts/VC JWTs/ 14:26:12 ... this was implicit in the vc jwt discussion, with a fully expanded model. 14:26:12 s/weve/we've/ 14:26:15 guest+ kgriffin 14:26:52 ... the number 1 potential problem is the versioning problem, if we think we have years between adjusting the core data model terms, versioning is less of a problem. 14:27:17 q? 14:27:27 ... we could potentially have a v-code or similar, or vc.v for version that has a string that gives programmatic rules to how to handle the versioning problem should this be an issue past v2 14:27:31 q+ to note versioning problems when you depend on media type 14:27:36 q+ to say Mike just reinvented contexts as "versionCode" 14:27:37 ... not sure we need to solve in v2 but we might have it after v2 14:28:00 brentz: the session lead has requested to keep it to pros/cons 14:28:07 kristina: suggest to keep queue till the end 14:28:51 q? 14:28:51 gabe: first possible solution adding @vocab to @context in v2. already merged. lowers the barrier to interop, you basically have a "default namespace". context isnt optional but it makes it easy for you to just pretend 14:28:53 q 14:29:54 Orie: one of the things that is helpful is to make the proposals clear before picking a winner. media types help clarify that. some of the media types have ld+json in them with the assumption that context is mandatory. some don't have them, so the ld specific syntax would not be required 14:30:09 ... it could have some additional rules and constraints for processing 14:30:30 gabe: the media type would then allow you to have/not have context even if the core model requires it 14:30:47 important to note that every new media type further splits the ecosystem by requiring another item software providers for every party must implement (issuer, verifier, holder), so dragons there. 14:30:56 ... next proposal is layering, if the semantic layer is present then you have @context if it doesn't it wouldnt be required 14:31:03 q 14:31:46 sam: a big part of our proofs conversation is about the authn layer. a JWT or ACDC would be at the authn layer. this allows people to have authz or authn without impinging on the other layers. 14:32:16 ... this means we don't have to specify in this data model how to construct the payload. the entire idea behind holder binding is sometimes things mean the same things and sometimes they don't 14:32:28 Identitywoman has joined #vcwg 14:32:29 For the record, here is an example of a versioned media type: https://www.iana.org/assignments/media-types/application/vnd.cncf.helm.chart.content.v1.tar+gzip 14:33:18 Here is another example of a versioned media type: https://www.iana.org/assignments/media-types/application/vnd.ims.lti.v2.toolsettings.simple+json 14:33:22 ... authenticator proofing would be in the authentication layer and semantic proofing would be in the semantic layer, separating these concerns allow us to innovate as we would now support more use cases atleast on the auth-n layer 14:33:56 ... we would then have hard choices on the semantic layer, but that gives us the trade off: wide-adoption vs narrow adoption with greater interop. and i don't think we can get wider adoption wihtout separating the layers 14:34:30 i'm hearing people say "there is more than one concept of interop" ... and "interop goes up when we add more ways to do things" ... my "concept of interop" says just the opposite ... the more things every one must implement the less interop. 14:34:33 gabe: last option is transformation option, transform and get dressed for the right occasion 14:35:06 ... if we can't agree to any of these 4 options i believe we will end up with FO and in the pit of death 14:35:13 q 14:35:14 ... lets just pick one or come up with something else. 14:35:43 Queue a re-read of the mission of the WG 14:36:11 kristina: going down queue please argue for option you prefer, to find something concrete. lets try not to rerun the old comments 14:36:13 ack ChristopherA 14:36:41 q+ 14:36:46 How the translation option handles proof? 14:36:58 christopherA: Thanks everyone. im in a future proofing mode, these standards take a long time to ratify etc, i'm looking at a number of different emerging areas in security. my biggest issue is the layers problem. 14:37:43 also SHOULD vs MUST with carve out for cases in another WG that is seeing high levels of adoption https://www.w3.org/TR/activitypub/#obj 14:37:49 ... I agree with Sam there are real issues with the current proposals, that aren't future proofed against a variety of future auth-n methods, looking at things like escrow encryption or access to encrypted data. 14:37:51 kristina nvm I was just remembering the mission of the WG: "The mission of the Verifiable Credentials Working Group is to make expressing, exchanging, and verifying credentials easier and more secure on the web" 14:38:30 ... looking at herd privacy concerns, for e.g. harvard issues a single credential for all graduates of a year this allows for herd privacy etc. 14:39:20 ... also looking at future graph models, JSON-ld really focuses on node graphs, I see some real merit to edge graphs. I think some of these are hard to do in the working group timeline. I would love to do this work on layering but I doubt it won't be done in this timeframe. 14:39:21 +1 to ChristopherA on time constraints 14:39:36 q+ 14:39:49 +1 christopher - also some items may not be in scope and would possibly need a re-charter 14:40:03 +1 to focusing on the options we have documented, and if they can work. 14:40:09 q? 14:40:15 ... I would vote for 3, but I think we don't have the time for it so I would vote for option 2 as a way to read profiles. so with the profile that is VCLD we can work to make it as locked down as possible and allow people who don't want to use it not to 14:40:17 q+ to state that option 2 is not in conflict with option 4 14:40:25 ack kgriffin 14:40:54 ack Orie 14:40:54 Orie, you wanted to talk about definitions 14:40:55 I've been doing a lot with CBOR 14:41:02 I'm not seeing how XML is a 'pro' column item.. 14:41:09 kgriffin: going back to pros slide, one that is missing is XML. one of the things we have found missing is the XPRS standards group, and they have expressed desire to express vcs in that format 14:41:27 Identitywoman has joined #vcwg 14:41:43 Orie: no surprise here im a strong supporter of option 2. there is a world where we only define media types in the core data model and option 2 gives us that. 14:41:46 XBRL -https://www.xbrl.org/the-standard/ 14:42:04 big +1 orie 14:42:24 ... the reason I queued is because we keep mentioning verifiable credential but its a non-normative description. I like the idea of media types and concrete description of media types and their restrictions 14:42:25 massive +1 as well 14:42:37 selfissued has joined #vcwg 14:42:47 present+ 14:42:57 +1 on versioning in the content-type 14:43:05 @Orie - do you mind explaining Option 2? What does media type do to context? 14:43:09 ... speaking to versioning consideration is media types have been versioned before, and we can version at that layer, and it can have constraints at the content it is referring to. digging in to the content to find version is something im opposed to. 14:43:24 +! (can i have a stronger ++1) to orie 14:43:52 +1 to explaining the relationship between media types and it's impact on context 14:43:55 ... option 3 im super against. layering is a consideration for media types. if we decide as a group that we will do layering across media types, I think option 3 might be a path forward, but if we try to do layering in one media type it will be problematic 14:43:55 -1 to thinking media types "solve the problem" ... because they don't help with the interop issue, the more media types there are, the less interop; media types can only help so much, mixing with option 4 would help 14:43:55 observing that option 4 does not have to happen after option 3? 14:44:28 ... option 4 transformations is a subset of media types. you start with 1 media type transform to a second one, which is a valid approach. It has a problem with the definition problem. 14:44:48 q+ 14:44:53 ... CBOR-LD is a transport format, it is a transformation from a JSON-LD VC to a CBOR-LD "VC" 14:45:25 Option 4 Transformation = new name for Abstract Data Model :) 14:45:25 q? 14:45:25 ... I see options 3/4 as a subset of option 2 and option 1 is insufficient 14:45:25 ack manu_ 14:45:25 manu_, you wanted to note versioning problems when you depend on media type 14:45:31 can somebody explain option 2? 14:45:34 Q+ 14:46:05 q+ to ask how option 2 works with embedded proof creds 14:46:08 q+ 14:46:14 q+ to ask if option 2 is compatible with `ld+json` and `.jsonld` 14:46:29 q+ to "the problem to be solved" should not be to create small islands of different types of content where there is no interop 14:46:31 manu: I don't think option 2 solves the problem. We are talking about an outer format that specifies the media type and an inner format. those two will get separated from each other. the inner document will not have versioning information or context which is the biggest issue with option 2. 14:47:09 q+ to ask if somebody can expand Option 2 (what does it mean exactly)? 14:47:33 ... option 2 splits the two things apart and they cannot be reconstituted together. Option 2 also makes it such that we agree on non-interop, one subset will go do things without @context, and another groups will do it with @context 14:47:39 +1 that option 2 as a general "solution" is the opposite of a solution, it just creates divergence. 14:48:01 ... we are going to see divergence and we have agreed that we are making it less interop as a group will be going one way and another group going the other. 14:48:13 +1 to the importance of preserving decentralized extension abilities. That's key in ed/training/workforce dev areas. 14:48:16 +1 option 2 is capitulation... it is "give up on interop and everyone go to your own corner" 14:49:00 ... i agree that option 4 is hand wavy. There is a subset that we have no idea how to solve a number of transformations, and I don't know how to do those. if we do option 4 we will need a registry and I'm concerned about option 4. 14:49:39 ... option 3 takes too much time, but we already have a layered solution. I'm not hearing is what technical reason why option 1 does not work for you 14:49:48 ... what is the tech burden on your interop 14:49:57 q? 14:50:03 q+ 14:50:13 ... option 1 is a compromise and it I believe addresses all the tech concerns that were raised. 14:50:17 q? 14:50:21 ack JoeAndrieu 14:50:21 JoeAndrieu, you wanted to say Mike just reinvented contexts as "versionCode" 14:51:02 joe: the primary value of @context is the decentralized disambiguation i dont care about the graph model n-quads etc. All i care about is the decentralized disambiguation. 14:51:27 We solved for this in did core, with by using media types. 14:51:46 ... not a new debate, we had this debate in DID WG. I don't understand these two camps, JSON-LD is JSON, I don't understand why this one property is called out other than for commercial/political reason. 14:51:47 q? 14:52:05 technical reason, as stated before, is prevention of reuse of terms/data and deviation/conflict from registered claims - cty would be a MUST so not being able to know what an object is when you get it is a non-argument 14:52:12 ... I think option 1 is a sufficient compromise. but I haven't yet seen compromise from the pure json crowd of how to do decentralized disambiguation. 14:52:16 +1 Joe, vocab has been an improvement.. but imo, it was fixing a bug, not a compromise on a feature. 14:52:20 markus_sabadello has joined #vcwg 14:52:22 q? 14:52:30 ... I want to respond to mike's comment about version code, you recreated context. 14:52:34 mike: in a shorter way 14:53:11 joe: decentralized disambiguation allows any community in the world to define the vocab that matters to them and allows them to use it as an equal peer. similar to how any css on a page is treated the same 14:53:31 ... people processing VCs should have a first class mechanism to process semantics around VCs 14:54:28 ... responding to lets interop with credentials that are worth interoping with. but that is the top down authoritarian view, we should not be the org that judges which vocabulary is worth anything. 14:54:47 Gabe: my understanding of that is that each implementer should say which credentials they interop with. 14:55:02 @gabe - it's also up to implementers whether to conform to the VC spec, too. that's a valid choice 14:55:21 +1 to decentralized communities defining their own vocabs and supporting the communities they serve. 14:55:25 +1 to Joe 14:55:25 We are chartered to make breaking changes... we can change the normative requirements. 14:55:29 +1 Joe 14:55:29 Joe: pushing back on framing that VCs are ambigous, this group formally defined VCs. you can in other context other than W3C but in the W3C we formally defined a consensus driven spec about what VCs are 14:55:38 +1 Joe 14:55:42 +1 to the value of shared, decentralized vocabs 14:55:53 kristina: timebox for 20m then run poll then argue about poll results 14:56:03 kristina: running poll at 10:15 14:56:05 ack Phil_F 14:56:07 q? 14:56:31 Does Option 2 explicitly mean - "@context is optional for some media types"? 14:56:35 q- 14:56:52 ack markus_sabadello 14:56:55 phil_f: I agree with option 2/4, but with an eye towards approaching option 3 in the long view. One of the reasons I like it is because the VC JWT presentation opened the door to a VC ACDC 14:57:12 You will need a media type for ACDCs, if you want browsers and software to handle them. 14:57:53 +1 Orie 14:58:05 dropping form q since i must hop on a call - poll wise, i intend support JWTs, i am happy with option 2, and would contribute work towards 4 in conjunction with option 2 to promote semantic mapping to the VCDM 14:58:21 markus: to me option 2 is the really big tent where VCs are a high level generic term that can mean anything, wondering if I don't understand it correctly. If i look at the VC JWT v2 violates the core VCDM in certain ways, it does not have an @context and no issuer/credential subject and don't know how that fits in together. the freedom in option 2 leads to very little technical similarity. 14:58:31 ... I think option 2 is problematic. 14:58:44 ack Paul_Dietrich_GS 14:58:48 q 14:59:37 markus_sabadello has joined #vcwg 14:59:45 paul: to weigh in from GS1 world, we're here because we want trust about the product to move with the data, and unless it travels over a secure network it is hard to trust the data. if the package size is wrong and i'm doing shelf planning then i'll get things wrong 14:59:45 I asked ChatGPT, here is our answer: https://pasteboard.co/N9ODQkg7nS6r.png 15:00:18 ... if they will share that data through w3c VC, I see option 2 is that every retailer has to define their own version. 15:00:18 +1 to Paul 15:00:22 ... verifiers will need to implement it all, so i see option 2 as problematic in that sense. I don't know enough at option 4 is that it is not easy. I don't know whats wrong with option 1. 15:00:57 ... when you see the product weight on a brand on a retailers website and I see option 1 is not trusted because we haven't found a way to sign it. I don't know enough about option 2/3. 15:01:04 https://www.w3.org/TR/json-ld11/#interpreting-json-as-json-ld 15:01:10 ack Identitywoman 15:02:29 Agree JSON-LD is in market, disagree that its the only media type in market. 15:03:04 identitywoman: I just joined an advisory group in higher education and the call this week we're trying to align the vocabs of a million credentials and 60,0000 institutions. and its all going to align because we have RDF and JSON-LD, and the people who are saying that format doesn't matter feel out of touch. because its in market for atleast higher ed, so i wanted to name that, and wanted to know that reality and wanted to add support to Joe'[CUT] 15:03:12 ... I support option 1 15:03:19 ack decentralgabe 15:03:19 decentralgabe, you wanted to ask how option 2 works with embedded proof creds 15:03:51 Gabe: No one is saying JSONLD is not useful in many cases but it si jsut not useful in some, and in those cases it shouldn't be used. I think you can imagine an embedded proof credential that is not a JWT so i think option 4 tries to address that. 15:04:13 q+ to say media type layering is necessary (and so the set of 4 is not quite the right categories) 15:04:15 ack selfissued 15:04:42 q+ 15:04:58 selfissued: Some reactions to things peoples have said: to manu's point about separating media types from content, if the content type is in the cty field it is part of the signed data, so unless you will pass the credential without it being verifiable. it is always part of the secured content 15:05:46 ... decentralized disambiguation is not always necessary. I support your goal but I'm saying its not always necessary is because from the real world application context you will know what kind of things you are willing to receive. 15:06:02 @selfissued - but for those narrow real-world use cases, one doesn't need to conform to any spec, either. 15:06:30 ... these are usually specified in the application context, if you will receive a covid credential, there are a few formats that are innumerable, but some jurisdictions you will specify which ones you are willing to accept 15:07:14 ... what you need is to read the specification to write the code to use it, which might be a binary blob and only when you read the spec you will know that it is a picture of a person, you will need to read the spec to understand it 15:07:50 ... i understand the value of runtime typing. using the specs that define application data, that does not go away if theres a context or not which is why im repeating the point that real world application context tells you what you will receive 15:08:40 ... trying to answer manu's question about what is the requirement that is met by making @context optional. it is listening to developers. some of them support it and some of them find it unnecessary. there are many thigns that are VCs that are not spec compliant that are deployed 15:08:56 q? 15:09:01 "Developers want X" is not a technical requirement -- what problem are they trying to solve and how does @context prevent them from achieving their technical goals? 15:09:05 ... developers have voted with their feet that they consider linked data a tax, and many of them have voted to not pay it if it is not necessary. 15:09:23 ... yes we have defined the requirements on jwt vc v2. so i support option 2 15:09:24 ack Orie 15:09:24 Orie, you wanted to ask if option 2 is compatible with `ld+json` and `.jsonld` 15:09:42 q+ to request that PR#44 is reverted given that it was merged without consensus and people are starting to cite it as having consensus. 15:10:18 Orie: the jsonld spec uses media types to describe its normative requirements, thats how you know it has to have a context. in the VC DM 1.1 spec it says the @context is a member of the VC's it does not have a media type 15:10:56 ... in 2.0 vc+ld+json will bring these requirements and option 1 implicitly admits media types to explain atleast 1 media type. the question is can VCs only be expressed as LD+json 15:11:52 ... if that is true the core data model should explicitely say that. if it is false the data model can only admit media types that accept it with extensions being done by the working group. in my view option 2 is consistent with the reality that different content on the internet must have different media types 15:12:01 q 15:12:03 q? 15:12:05 brentz has joined #vcwg 15:12:17 q 15:12:18 ... it is wrong in my opinion to mandate that interop can only be done on media types that are ld+json media types 15:12:19 ack dlongley 15:12:22 dlongley, you wanted to "the problem to be solved" should not be to create small islands of different types of content where there is no interop 15:12:57 q+ 15:13:09 dlongely: mine is a combination of options. first i want to speak to the issues with option 2, creating many media types increases the problem. having too many formats is the problem, identifying them better doesnt solve it it highlights it. I don't think we should have many small islands with different content. the three party model 15:13:23 q 15:13:41 q+ 15:13:49 I don't consider the interoperability supported by media type registries a failure, I consider it a success, and JSON-LD relies on it, search "ld+json": https://www.iana.org/assignments/media-types/media-types.xhtml 15:13:58 ... creates an open model that allows three parties that allow you to create and consume vcs in an open world model. there are many solutions for a closed world model, VCs were created for an open world model. 15:14:27 ... the more people create and reuse shared vocab the better things will be and @context is the mechanism to make it happen. 15:14:56 there are other ways to convey context than @context. 15:15:02 ... option 1 makes it easier for developers to create context. option 2 is great if it is a small number of media types but is not generalized solution 15:15:36 q? 15:15:38 @context is RDF/JSON-LD specific way of conveying semantic context. 15:15:59 ... option 3 has parts that can be pulled in, layers are great but every different type of tech used at different layers can be harmful to interop. option 4 if we combine with option 2 with limited media types can be helpful 15:16:23 ... as we can always translate to a common format, allows different software that only needs one format can use just that one format 15:16:41 -1, the options are not sufficiently well defined 15:16:58 +1 dmitriz 15:17:01 Identitywoman has joined #vcwg 15:17:13 Option 1 15:17:15 Option 4++ would be Abstract Data Model with deterministic transformation between all media types 15:17:23 Paul_Dietrich_GS1 has joined #vcwg 15:17:34 brent: i think that although there is some overlap with each of these options suggesting there is enough clarity for you to say I like 1 and 2 15:17:56 option 2, to me, says "create as many formats as you want, just make a new media type" 15:18:00 Dimitry: option two says context is optional for some media types? 15:18:07 Orie: that is already true for some media types 15:18:08 My poll answer: Options 1 or 2 are acceptable compromizes, I wish for 3 but we should be separate track. 15:18:10 option 2 is "do whatever you want as long as you tag it with an identifier" 15:18:11 q+ 15:18:25 please put your preference 15:18:29 Option 1 15:18:31 2 15:18:34 Option 1 15:18:34 2 15:18:34 1 15:18:37 1 15:18:44 4 15:18:54 Option 2, 4 15:18:56 1 15:18:57 2,4 15:18:57 1 15:18:58 Option 1 15:19:01 1 15:19:02 1, 2, 4 15:19:06 1,2,4 15:19:06 1,4 (the two are equivalent) 15:19:13 2,4 15:19:17 1, 2 15:19:20 4,2,1 15:19:21 2 15:19:22 2,4 15:19:23 2, 4 (4 only if clarification on proof. I don't understand about proof) 15:19:28 Option 2/4 with eventual consideration of 3 15:19:43 3 is just a tautology -- layering's good, so what 15:19:45 1, 2, 3, 4 15:19:54 no on 3 ... yes on mostly 1 with 4 and a small dose of 2 15:19:59 My proposal for option 3 is that we admit it should be done, but in in immediate. 15:20:08 q 15:20:25 Sam and I (and others) need ability to work on 3 15:20:28 +1 ChrisopherA 15:20:49 kristina: looking at the poll can you gray out option 3, as there is interest to explore in the future but not right now. 15:20:54 (and don't sabotage I it ;-) ) 15:21:15 decentra_ has joined #vcwg 15:21:17 q+ 15:21:18 Option 3 sound like it could fit well in a V3 15:21:22 3 requires application of the others, so a vote for 3 is a vote for the others, imo 15:21:24 q? 15:21:29 +1 to don't sabotage it. 15:22:18 q+ to ask option 1 says nothing more, the others are doing more, how can we do both? 15:23:00 joe: i think these things are interestin gto consider, the question is, is context optional or not. 15:23:40 dimitry: option 4 makes it so that it is required but mitigates some of the costs 15:23:40 +1 to dmitri's description 15:23:40 q? 15:23:40 s/ interstin gto/ interesting to/ 15:23:44 decentr__ has joined #vcwg 15:24:06 kristina: i think people are trying to elevate it beyond making it optional, its one property. 15:24:16 q+ to suggest @context is mandatory, but you can transform to formats that don't have it, as long as you can get it back to its original form. 15:24:19 ... we now know that option 3 is not achievalbe in this charter 15:24:52 option 1 and 4 are exactly the same 15:25:11 brent: if context is optional what can you do that you cannot make before 15:25:54 kristina: lets go down the queue for 10 mins before the break. 15:25:58 ack dmitriz 15:25:58 dmitriz, you wanted to ask if somebody can expand Option 2 (what does it mean exactly)? 15:26:33 oh, option 2, 4 for mprorock 15:26:37 q+ to what problems does making @context optional create 15:26:39 dimitriz: i feel the options are somewhat misleading because 1/4 are equivalent. options 1 and four have no loss of info between converting between media types. it is saying when converting from one media type to another we will lose information 15:26:40 he put in the chat earlier 15:26:44 q? 15:26:48 ack dwaite 15:26:50 thats not correct, you don't loose information when a server sends you text/html. 15:27:13 @Orie - should the various representations of VC be losslessly transformable between? 15:27:15 q+ to XML-LD -- no, refer to the XML file 15:27:35 dwaite: somone asked what are the limitations of having @context, we had people want to do XML, there is no XML-LD. CBOR-LD you can say a 4 byte context without transformation is not a VC because it does not have a literal @context field 15:27:43 -1 to any argument that says "people can't define whatever they want and have it be a v2 VC" ... that's what v3 is for. 15:28:09 ... thinking of the market people have adopted broad strokes of open id, but we have seen independent effort including some work at ISO, compared to what we have produced it looks alien. 15:29:01 ... my concern is if people do other formats to do their own needs, it will make interop harder, which is why im in favour of option 4. 15:29:01 interoperability is a *technical* consideration, it is not about branding. 15:29:01 I can't +1 "xml-ld is not valid vc, has no context." enough 15:29:01 Its as if the working group wants to make Verifiable Credentials exclusively defined in RDF... perhaps thats a way of tackling this. 15:29:03 ... it gives people clear guidance saying. This does not make us hostile to those other credentials. 15:30:05 This whole discussion, all these 4 options, all boils down to "Should implementers and consumers be able to convert between media types / representations losslessly?" That's the key. option 1 & 4 says "yes". Option 2 says "nope, information loss is ok" 15:30:09 ... i know customers of mine want to do straight json, they will get value of JSON-LD. I will say in the question of retailers and shelving it allows people to define them in other ways. in jwts you can create collision resistance identifiers, you still need a group to get together. 15:30:15 q+ to speak to limiting options 15:30:52 ... JSON-LD does not solve that problem, you can do that with any flexible format that does not require registration. I'm in favor of transformations. 15:30:53 Phil_F has joined #vcwg 15:30:54 "you can do that with any flexible format" => "we have to make choices, we're a standards group" 15:31:02 q? 15:31:03 ... if we draw a hard line in the sand then what we want the market to embrace may not happen 15:31:13 ack JoeAndrieu 15:31:13 JoeAndrieu, you wanted to say media type layering is necessary (and so the set of 4 is not quite the right categories) 15:31:43 q+ 15:31:58 joe: we're going to need multiple media types, the right way is through layering, i was confused why they were separated. we do not want multiple independent serialization. we should have a base media type, such as credential+ld+mediatype 15:32:00 +1 to JoeAndrieu 15:32:05 +1 to Joe 15:32:29 yes, media types aren't "bad", but using them as a solution where we just name every different format and accept them all is "bad" 15:32:31 ... we need media types and if we have a cbor-ld representation of json-ld we need to indicate what it is. 15:32:47 ... lets be clear adding xml is not additional interop. 15:32:56 +1 to Joe about increasing interop and not decreasing it. 15:33:25 q+ to speak to DID spec and why it didn't work out well. 15:33:42