22:59:05 RRSAgent has joined #vcwg-special 22:59:05 logging to https://www.w3.org/2022/11/22-vcwg-special-irc 22:59:18 zakim, start the meeting 22:59:18 RRSAgent, make logs Public 22:59:19 please title this meeting ("meeting: ..."), brent 22:59:28 meeting: VCWG Special Topic Call 22:59:34 chair: brent 23:00:57 selfissued has joined #vcwg-special 23:01:08 present+ 23:01:51 dlongley has joined #vcwg-special 23:01:55 Orie has joined #vcwg-special 23:02:01 decentralgabe has joined #vcwg-special 23:02:01 present+ 23:02:09 present+ 23:02:20 present+ 23:03:19 scribe+ 23:03:48 manu has joined #vcwg-special 23:03:53 present+ 23:04:04 brent: The topic if about issues around `@context` optionality and `@vocab`. 23:04:11 Logan_Porter has joined #vcwg-special 23:04:11 brent: There are proposals that seem to be nearing some consensus. 23:04:25 brent: In order to tease that out, we plan on running some polls and hope to make progress. 23:04:35 DavidC_ has joined #vcwg-special 23:04:39 brent: I have some that I can run and I also open it up to people to run polls to others as well. 23:04:41 nadalin has joined #vcwg-special 23:04:47 present+ 23:04:47 brent: Straw polls and polling should be a useful tool for us today. 23:04:54 present+ 23:04:56 present 23:04:57 = 23:05:03 q+ 23:05:10 ack selfissued 23:05:13 present+ 23:05:21 selfissued: I'd prepared a few poll questions that I think would get to the heart of it. Do you want them in the chat? 23:05:31 brent: You could just drop them in IRC one at a time and we can see how people feel about them. 23:05:33 selfissued: Ok. 23:05:48 Mike's proposed poll 1: "Which are you aware of VC or VC-like deployments that do not use @context or do not use it in a JSON-LD compatible way?" 23:06:10 tplooker has joined #vcwg-special 23:06:15 present+ 23:06:21 q+ 23:06:23 Mike's proposed poll 1: "Which of are you aware of VC or VC-like deployments that do not use @context or do not use it in a JSON-LD compatible way?" 23:06:24 q+ 23:06:28 q+ 23:06:33 ack Orie 23:06:34 brent: Let's clarify, jump on the queue. 23:06:44 drummond has joined #vcwg-special 23:06:52 present+ 23:07:12 Orie: The words "VC-like" ... are we talking about any situation where arbitrary data is signed with crypto and verified? Are we talking about google's libs for signing arbitrary content, are we talking about signing protocol buffers, how far away from signatures on structured data? 23:07:25 shawnb has joined #vcwg-special 23:07:30 kristina_ has joined #vcwg-special 23:07:36 selfissued: My intent was for the credentials to look a lot like what the credentials look like, using the VC members, but not in a conformant way. 23:07:46 shawnb_ has joined #vcwg-special 23:07:53 selfissued: I wasn't looking at bringing in protocol buffers, etc. 23:07:53 ack DavidC_ 23:07:53 present+ 23:07:59 selfissued: Just if you squint and it looks like a VC. 23:08:00 present+ 23:08:14 DavidC_: What does "aware" mean? Could we alter this to be direct experience with? 23:08:26 I'm aware of several "non conformant" implementations of W3C Verifiable Credentials. 23:08:26 DavidC_: "Aware of" -- you hear gossip on channels, it doesn't mean it's necessarily true. 23:08:39 selfissued: I'm trying to establish facts on the ground which we did talk about at TPAC. 23:08:50 selfissued: There's a lot of things in my experience that are like this but not. 23:09:03 Orie: Likes to point out the SmartHealth credentials that could have been a VC but is not. 23:09:04 I wish I could use the DEF header. 23:09:08 on a JWS. 23:09:30 selfissued: I'm not trying to wordsmith this -- I don't want it to take 10 minutes, I just want to establish it is happening in practice. 23:09:30 ack manu 23:09:44 Mike's proposed poll 2: "Representations of the VC 2.0 data model must be restricted to only JSON-LD." 23:09:46 manu: I don't think it's useful to identify implementations that are knowingly breaking specifications. 23:10:16 manu: I feel like we're repeating things that were said in that long thread. It's like asking "How many of us know a developer that refuses to follow the specification?" Even though many people do follow the spec. 23:10:22 Mike's proposed poll 3: "It must be possible to have credentials that do not require @context processing." 23:10:28 yeah I believe its important to acknowledge reality and understand why this is the case 23:10:40 Mike's proposed poll 4: "It should be possible to syntactically determine when JSON-LD processing is required and when it must not be performed." 23:10:46 q? 23:10:47 q+ 23:10:50 Mike's proposed poll 5: "Interoperability can be achieved without a graph-based data model." 23:10:52 manu: I think this only establishes that there are people that don't want to use this value even though there are multiple things that would allow them to use it. We have data over multiple years, there are people that have implemented the issuing of VCs, if we just look at the latest plugfest, I believe there were zero implementers that didn't use `@context`. 23:11:09 q+ 23:11:20 manu: Are we optimizing for people that will read a spec and implement or someone else -- who are we optimizing for? I get that there are companies out there that do not want to implement `@context` but we have discussed this to death in that issue. 23:11:36 selfissued: It will establish that some developers aren't using the spec as written. 23:11:47 ack Orie 23:11:50 ack brent 23:12:05 q+ 23:12:28 Orie: One thing that would be helpful would be to look at something like the DID registries. When we see people registering DID methods, given the decision to make `@context` optional in there, of the entries in there, pretty much none of them, except for one, in the history of the ones I've reviewed... 23:12:57 Orie: Only one didn't include `@context` and the reason that they do that is to just include it because it's in the spec and they want it to work. 23:13:04 Orie: I think that's healthy and we should make it work. 23:13:04 q+ 23:13:30 Orie: I think that making something that looks like JSON-LD and RDF but doesn't have `@context` but has all the conventions and so on from that ecosystem will just be repeating the mistake made in the DID WG. 23:14:01 Orie: All the dev experience, all the things making VCs more valuable from a regular JWT or JWS comes from this ecosystem that has been developed in the W3C. It's a waste of time to remove this one member that provides this valuable distinction. 23:14:28 Orie: From a JWT that also is a standard with claims about subjects and a VC that also has claims about a subject but an open world data model many of us came here to work on. 23:14:50 Orie: I think we could get to a valuable solution, instead of making `@context` optional, to a solution that makes it easy to use where we don't have to talk about it again. 23:15:14 ack brent 23:15:18 Orie: There are proposals that I'm in favor of, we don't have to get to them right now, but establishing that devs don't fully read specs doesn't seem like a useful statement. It also applies to JWT and alg=none and any other standard I've ever read. 23:15:28 brent: Thank you, Mike for the first poll. 23:15:34 brent: Can I run the second? 23:15:44 selfissued: If you dont' want to run the first one, the second is fine. 23:15:52 Representations of the VC 2.0 data model must be restricted to only JSON-LD. 23:15:53 selfissued: Please decide to run it or not, I dont' want it to take up a lot of time. 23:16:02 +1 23:16:02 -1 23:16:03 -1 23:16:04 -1 23:16:04 -1 23:16:05 +1 23:16:05 -1 23:16:07 +1 23:16:16 +0 23:16:24 TallTed has joined #vcwg-special 23:16:39 +1 23:16:41 brent: We don't have agreement there, the point is to tease out where we agree and where we don't. 23:16:52 selfissued: Ok, we've determined something. 23:16:58 It must be possible to have credentials that do not require @context processing 23:17:06 +1 23:17:07 +1 23:17:07 +1 23:17:08 +1 23:17:08 =1 23:17:11 shawnb has joined #vcwg-special 23:17:14 +1 23:17:17 +1 for some definition of context processing :) 23:17:19 +1 23:17:20 +1 23:17:21 +1 23:17:28 +1 (to some definition of @context processing) 23:17:29 +1 23:17:29 +1 23:17:34 +1 23:17:49 brent: I think every +1 is for "some definition of context processing" 23:18:13 Mike's proposed poll 4: "It should be possible to syntactically determine when JSON-LD processing is required and when it must not be performed." 23:18:18 +1 23:18:19 q+ 23:18:21 +1 23:18:22 +1 23:18:23 dmitriz_ has joined #vcwg-special 23:18:23 -1 23:18:24 -1 23:18:28 -1 because JSON-LD processing is not clear 23:18:28 q+ 23:18:34 +1 23:18:37 +1 (for some definition of JSON-LD processing) :0 23:18:41 ack selfissued 23:18:44 dmitriz has joined #vcwg-special 23:18:47 scribe+ 23:18:49 ack dlongley 23:19:09 present+ 23:19:10 dlongley: I think we've really got to come to a shared understanding of JSON-LD PRocessing, or using that term, everyone has a different version of what that means and we keep getting stuck on it. 23:19:15 -1 because it shouldn't be required or not required data consumers should be able to do it if they want to and its available 23:19:36 ^ yes, tobias 23:19:39 agreed. its a decision of the verifier 23:19:41 dlongley: What we need in the spec is "not use json-ld library, but you might be able to do string comparison on a field" 23:19:49 ack Orie 23:20:04 q+ to provide some more polls. 23:20:05 Orie: I was going to say something sort of similar. I think the poll is not precise enough to provide meaningful value in terms of really understanding what's going on here. 23:20:12 Orie: I agree with Tobias's comment in the chat. 23:20:44 q+ 23:20:49 selfissued: What is your sense of this poll? 23:20:49 q+ 23:20:55 brent: Makes a bit more support than not but no where near consensus. 23:20:56 Interoperability can be achieved without a graph-based data model 23:21:05 +1 23:21:06 +1 23:21:06 +1 23:21:06 q+ 23:21:08 +1 23:21:08 +1 23:21:08 -1 23:21:10 -1 23:21:13 -1 23:21:16 +1 23:21:18 +1 23:21:19 -1 interop on what? another standard? :) 23:21:45 but i'd still like graph data so ... :shrug: 23:21:47 agree, 'interoperable' is a vague term 23:21:50 brent: Once again, no real consensus coming out there. 23:21:56 ack manu 23:21:56 manu, you wanted to provide some more polls. 23:21:59 ~0 yeah I mean agree with manu here if we had something new 23:22:12 q- 23:22:14 -1 (it would require starting with complete destruction of VCDM 1.0) 23:22:19 manu: I wanted to try with some language ... where we were able to sit down with multiple people at IIW to come to consensus around it. I'd like to speak to them before running the polls. 23:22:27 yes TallTed. 23:22:32 thats correct. 23:22:42 manu: I think these were consensus positions at IIW -- I'd like to stick on each one and have a little more discussion. I think like the proposals Mike put in there -- I think it's easy to misunderstand what certain words mean. 23:23:11 q- 23:23:12 manu: Let me go to JSON-LD algorithmic processing and maybe fine-tune that. Perhaps we can get some kind of detailed view of "JSON-LD processing" 23:23:22 JSON-LD algorithmic processing of @context is not required, but must not be broken for JSON-LD processors, either. So, you don't have to process it, but you can't include a value that blows up JSON-LD processors either. 23:23:53 q+ 23:24:17 I agree with the intention of it, but i hate the language 23:24:17 manu: This does presume `@context` is not optional, it must be included, but it doesn't have to be processed if you have another way to process it. 23:24:21 +1 23:24:21 +1 23:24:22 -1 23:24:24 and importantly you do not need to resolve the value of the context, because the terms can be defined in a spec 23:24:26 +1 23:24:27 +1 23:24:27 0 23:24:27 +1 23:24:30 -1, do not understand why all JSON only developers whose VCs will highly never enter JSON-LD processor, have to account to not breaking all JSON-LD processors... 23:24:31 +1 23:24:32 0 because I'm in the queue 23:24:33 +1 23:24:39 +1 23:24:40 +1 23:24:50 +1 23:24:56 +1 but also don't agree with language as it should be ignored if not understood 23:25:06 +1 nadalin 23:25:13 ack DavidC_ 23:25:17 @kristina - that's equivalent to saying -- why should developers follow the spec, just to avoid breaking processors 23:25:48 DavidC_: I was on the queue to talk about a credential vs. a verifiable credential -- and I think that matters based on VC-JWT or not. 23:26:06 DavidC_: My answer to the 4th poll changes based on whether it's a credential or verifiable credential. 23:26:10 ack selfissued 23:26:38 q+ 23:26:39 selfissued: Yes, I agree with the you don't have to process it part. But I'll note Manu's poll question places additional burdens on issuers that are not currently present in the spec. 23:27:08 -1 23:27:14 selfissued: In particular, he's saying the `@context` needs to result in valid JSON-LD which isn't in the spec today. I could live with the poll if `@context` is optional but not if it's required. 23:27:18 ack manu 23:27:37 manu: To clarify that, Mike, the idea here would be an issuer that's issuing would set `@context` to effectively a hard-coded value. 23:27:46 q+ to suggest a greenfield data model. 23:27:48 q+ 23:28:01 manu: If you have an issuer that doesn't want to use `@context`, and they don't include it, it breaks all / most of the processors out there today. 23:28:42 manu: Let's go with your assertion, Mike, and say that there are issuers that don't want to use this and they put a value or two values that send a signal to JSON-LD processors that says "this thing I'm creating has private claims in it and I'm communicating that to the vast majority of the ecosystem that speaks that now". 23:28:55 manu: The extra burden on those issuers is a single line of code that injects the same static value in their VCs. 23:29:39 manu: I'm arguing that that burden really isn't that much of a burden. Having a one-liner that puts a static value in there that doesn't change is the compromise that give people who don't want to process `@context` what they want and it wouldn't break the ecosystem system of processors that do use it. 23:29:39 ack Orie 23:29:39 Orie, you wanted to suggest a greenfield data model. 23:29:59 Orie: Bear with me for a second. I'd like to just pretend for a second that VCs don't exist at all. 23:30:10 Orie: You're sitting down to build a new way of expressing claims about a subject that are protected by an issuer. 23:30:34 Orie: You've got some really wonderful specs at IETF, you can use JOSE, COSE, maybe you don't like the work at IETF, so you use protocol buffers with raw signatures on top of them. 23:30:42 Orie: Maybe you want a ZKP thing with a custom data model around it. 23:30:48 zakim, who is here? 23:30:48 Present: selfissued, Orie, dlongley, brent, manu, DavidC_, Logan_Porter, nadalin, tplooker, drummond, shawnb, kristina_, dmitriz 23:30:50 On IRC I see dmitriz, shawnb, TallTed, kristina_, drummond, tplooker, nadalin, DavidC_, Logan_Porter, manu, decentralgabe, Orie, dlongley, selfissued, RRSAgent, Zakim, brent 23:31:03 Orie: If we're really interested in building interop around that data model, we should define that data model and then we're talking about maintaining interop with respect to a specific data model. 23:31:10 present+ decentralgabe 23:31:24 Orie: One of the challenges with the work from the DID WG and what's being contemplated here -- is that we have people suggesting we break parts of the data model and not take ownership. 23:31:54 present+ TallTed 23:32:09 present+ samsmith 23:32:14 q+ to move on to the next poll. 23:32:17 Orie: If we're doing this weird array JSON thing with hashes or repeating id and type everywhere ... if we're getting these influences into the data model, then maintaining interop is about what's there, but it's hard to see that destroying parts of the model helps. 23:32:23 present+ jandrieu 23:32:46 Orie: Maybe we do VCs in COSE ... and compact binary everywhere and there isn't any inheritance, nothing to maintain interop, no conventions to follow, nothing would be confusing if we just stopped following them. 23:33:04 Orie: I'm really not in favor of making `@context` optional here because it's destroying interop we worked hard to create. 23:33:35 Orie: But I'm very much in favor with doing that on a new spec with like COSE or something -- I'm excited about that. The problem is really, this particular approach of trying to basically say our data model is JSON-LD while not saying that. 23:33:44 q+ 23:33:49 Orie: I think it's really great to build a mandatory JSON-LD ecosystem where you don't have to do any JSON-LD processing. 23:34:16 Orie: And I think we have to talk about that more because we've mentioned it many times and we don't have clarity ... what does JSON-LD processing mean and if `@context` is required, what does it actually mean to data that's conformant to the spec. 23:34:25 q? 23:34:26 Orie: I think we have to be very careful about what does JSON-LD processing actually mean. 23:34:29 ack selfissued 23:34:50 selfissued: Manu had said -- it's not that hard for issuers, you can just put a constant string in your JSON and your done. I understand that and we could even land there. 23:35:05 q+ 23:35:15 kristina_ starting something new in IETF would make sense only if w3c data model requires JSON-LD representation and processing, I'm in favor of doing this... personally. 23:35:18 q- later 23:35:21 selfissued: Dmitri made a proposal in the longest issue of all time. He said if `@context` is missing, then people should interpret the result as if it was present. And then the issuer doesn't have to put the string in at all. 23:35:27 q+ to note that dmitri thought better of that proposal, later in the thread 23:35:35 q- later 23:35:52 selfissued: To Orie's point about the IETF. I love the IETF, I think this WG will advance our overall goals of VCs and the privacy preserving model over all if we're inclusive of the various styles. 23:36:02 The 3 party model has nothing to do with W3C, its a function of cryptography... its not a "web" thing. 23:36:06 selfissued: Having more people produce legal VCs -- even if they aren't all the same, even if some are CBOR, it's better. 23:36:11 selfissued: We're in a WG to make things better. 23:36:12 ack decentralgabe 23:36:47 +1 to Kristina's comment about JWTs needing more to make them VCs 23:37:21 decentralgabe: I think there's misunderstanding where some see the value and need of JSON-LD and others just don't. How do we resolve that? The thing that's become most clear to me is that removing `@context` breaks interop. Maybe that's not valid, but what we don't want to do is break interop or get to the point where everything is different and there isn't enough interop.. 23:37:24 Yes, the ID Token is a profile of JWTs with some required claims and defined semantics for some of them 23:37:30 +1 gabe... lets lower the barrier, while maintaining interop. 23:37:39 +1 gabe 23:37:42 decentralizedgabe: I think what we want to do is get `@context` to be easy to use to get that interop without people needing to understand / use `@context`. 23:37:56 gabe: I think that including a couple of properties gets us there. 23:38:14 q? 23:38:19 ack dmitriz 23:38:21 q+ 23:38:21 gabe: It could be enumerating all properties in the spec itself -- I think all this does let more people produce more legal credentials and better than what we have today. 23:38:23 decentralgabe has joined #vcwg-special 23:38:42 q- as dmitri can speak for himself 23:38:44 dmitriz: I want to speak to my proposal on that thread about `@context` being optional and having a VC have default context. I did change my mind later on in the thread for a couple of reasons. 23:38:46 q- 23:39:10 dmitriz: The biggest one being, I realized that's it's not at all trivial for a processor to understand that, specifically, this JSON object is a VC and therefore apply the default context. 23:39:41 q+ to say that using @context as a meta-type makes sense to me. 23:39:42 dmitriz: I remember wanting to make the same proposal in the DID WG and have a default. Now we're dealing with a different JSON object ... and each one has its own default context and the rules for figuring things out get really complicated. 23:39:49 dmitriz: I dont' want devs to have to do that, so I retract that proposal. 23:40:20 ack manu 23:40:20 manu, you wanted to move on to the next poll. 23:40:25 -1 bad language 23:40:26 manu: So the only -1s we have are Orie because I think you don't like the language but we can fix that. We have Mike -1ing and he spoke but we haven't heard from Kristina's -1. 23:40:35 manu: That's it. 23:40:38 q+ to move on to next poll 23:40:42 brent: Kristina, do you want to speak to that? 23:40:45 ack selfissued 23:40:46 q+ 23:40:51 q- later 23:41:04 selfissued: I just wanted to make a process point, if there are valuable polls to run, we should run them before the clock runs out. 23:41:06 ack kristina_ 23:41:09 selfissued: We've had so much discussion on the issue I don't think we have to talk more here. 23:41:11 brent: I agree. 23:41:54 q+ to speak to "wallets" will move VCs around in a way that issuers can't predict. 23:42:00 JSON-LD is not mandatory to create or process a VC 23:42:06 kristina_: Not much to add. I think there are different ecosystems using different processors. If I'm a JSON-only dev and I'm not planning on using JSON-LD and the VCs I issue will never enter an ecosystem where a JSON-LD VC will be used. 23:42:17 q? 23:42:17 q+ 23:42:19 ack 23:42:24 ack brent 23:42:24 brent, you wanted to say that using @context as a meta-type makes sense to me. 23:42:46 q+ to say the three party model stuff 23:42:57 brent: The big thing I'm excited about is that an Issuer doesn't know where they will end up. 23:42:58 q- 23:43:14 brent: A holder is going to have a wallet, they could have VCs from all over the place and be able to use them all over the place. 23:43:16 +1000 to brent 23:43:30 brent: I don't think an Issuer can say "this will only be used here". 23:43:41 +100 VCs will travel much further and be used for much more than issuers conceive of at issue time 23:43:58 brent: That's my 2 cents. One of the concepts that came out of IIW was the notion that the `@context` property serves as a meta type for the VC. 23:44:14 brent: The first value says it's a VC and the second or subsequent values say what the specific type is. 23:44:38 brent: We have a type field that says the type of credential and the `@context` field says the "meta type". 23:44:41 q? 23:44:44 ack manu 23:44:44 manu, you wanted to move on to next poll and to speak to "wallets" will move VCs around in a way that issuers can't predict. 23:44:46 brent: I'd like to tease this out a little bit more and find the right language. 23:44:49 +1 to Brent's framing 23:45:15 SamSmith has joined #vcwg-special 23:45:21 q 23:45:30 manu: +1 to when an Issuer issues a VC, they in general don't know where it will be consumed -- a VC in a digital wallet can go anywhere and give that to a verifier that is highly likely to use other processing. 23:45:35 If a processor chooses to process @context, it may do that via simple string equality comparison that compares, at most, 1-2 URLs (to keep things simple). 23:45:59 -1 23:46:15 -1 23:46:26 0 23:46:30 The schema itself is the type. This is more precise. 23:46:31 +1 except i think it should be "must process, but the only 'processing' is string comparison" 23:46:35 +1 23:46:37 +1 23:46:39 +1 23:46:42 -1 23:46:43 +1 23:46:45 +1 23:46:50 +1 23:46:51 0 23:46:52 JoeAndrieu has joined #vcwg-special 23:46:53 0 23:46:57 +1 23:46:59 + what dlongley said 23:47:03 present+ 23:47:07 +1 23:47:14 I'm in favor of letting JSON-LD be JSON-LD whenever the issuer chooses to use it 23:47:23 this is asking people to always check the "meta type", IMO. 23:47:26 ack DavidC_ 23:47:52 JSON-LD is not mandatory to create or process a VC 23:47:55 DavidC_: It's been said, but I don't think Kristina's model is either in the spirit of keeping a VC model -- nor is it realistic. Once people have VCs in their wallet, they will use them wherever they want. 23:48:01 +1 23:48:01 +1 23:48:03 +1 23:48:03 +1 23:48:03 +1 23:48:04 +1 23:48:09 +1 23:48:15 +1 23:48:17 +1 23:48:17 +1 23:48:41 +1 23:48:47 We're voting on "JSON-LD is not mandatory to create or process a VC" 23:48:47 -1 23:49:02 -1 ('cause I'm confused) 23:49:09 https://www.w3.org/TR/json-ld11/ 23:49:13 People are +1'ing the removal of @context now? 23:49:18 People are +1'ing the removal of @context now? 23:49:44 JoeAndrieu: What does this mean? It's confusing. 23:49:50 +1 23:49:52 brent: I don't have to know about it to use VCs. 23:49:54 +1 23:49:56 +1 to "I don't gotta know about it to use VCs" 23:49:58 +1 just read the VC spec and you're fine 23:49:59 +1 23:50:01 +1 23:50:02 @kristina. this is where we want to get to :-) 23:50:15 JoeAndrieu: If it's just that statement, I agree. 23:50:26 brent: If I want to create or process a VC, I don't gotta know about JSON-LD. 23:50:46 JoeAndrieu: Are you writing the software or running someone else's software? A web user ... do they have to know HTML? They don't, end users don't. 23:50:49 do you need to know base64url to use a VC? 23:50:58 -1 23:51:10 brent: Should I be able to create a VC even if I know something about a JSON-LD. 23:51:28 selfissued: Is that a conclusive result or a lack of consensus? 23:51:49 manu: I'm concerned it's so vague that people are +1ing the definition in their own head. 23:51:59 manu: I think when we get into the details we might find -1s. 23:51:59 q+ 23:52:11 ack TallTed 23:52:14 TallTed: We've got a lot of commentary going in the IRC channel. 23:52:22 TallTed: I can't tell what we're polling on. 23:52:30 TallTed: Can we put "POLL:" in front of it? 23:52:34 Poll: A compliant VC must not break a JSON-LD Processor 23:52:36 brent: Yes, I apologize Ted. 23:52:42 +1 23:52:42 +1 23:52:42 +1 23:52:42 +1 23:52:44 +1 23:52:44 +1 23:52:45 -1 23:52:45 +1 23:52:49 +1 23:52:49 0 23:52:50 -1 23:52:51 +1 23:53:01 +1 23:53:03 @dmitriz interop comes with drag. One must balance the cost of the interop vs the value of the interop 23:53:08 -1 23:53:14 0 23:53:26 brent: three -1s on that, otherwise a lot of positives. 23:53:29 q+ 23:53:34 ack manu 23:53:44 manu: These polls, I'm just putting them in here, we got to consensus on these at IIW. 23:54:02 POLL: It will be illegal to fetch certain remote contexts from the Web (as outlined above). This will enable a usage of VCs that require no remote context downloading, reading, or processing (simple URL string comparisons can be used instead). 23:54:06 -1 23:54:20 -1 23:54:24 -1 When JSON-LD is used, really use it correctly. 23:54:33 0 23:54:38 +1 23:54:41 -1 to making it illegal but +1 to the rest :) 23:54:44 0 23:54:44 +0.8 23:54:52 q+ to one last ditch poll effort. 23:54:52 0 23:54:54 +1 23:54:57 +1 23:55:12 +0.3333 23:55:21 ack manu 23:55:21 manu, you wanted to one last ditch poll effort. 23:55:26 +1 to defining the context as immutable. 23:55:42 POLL: It will be legal to use @vocab as either a) specified in the first context, b) specified in the second context, or c) specified inline via @vocab in the second context position, or d) any variation of the previous options. 23:56:05 +1 23:56:05 +1 23:56:07 +1 23:56:08 +1 23:56:08 0 23:56:09 +1 23:56:11 +1 because it's a legal part of JSON-LD 23:56:12 0 don't care 23:56:14 +1 23:56:16 0 23:56:16 +1 23:56:17 =1 23:56:21 0 23:56:21 +1 23:56:22 +1 though this is a lot of options.. 23:56:22 +1 23:56:24 +1 23:56:24 +1 23:56:38 brent: That's one of two polls with full consensus today. 23:56:43 +1 23:57:29 q+ 23:57:33 brent: I think we've gone as far as could today, thanks for tuning in. I hope this helps people tease out where the disagreements are. I hope folks will reach out to one another. 23:57:45 brent: Please have conversations and work forward on this. I have great faith in this group to figure things out and come to agreement. 23:57:50 ack selfissued 23:57:55 happy thanksgiving all! (even though we kiwi's don't celebrate it!) 23:58:09 selfissued: Request to the chairs, could you please, in the minutes or a subsequent email, give your sense of each of the disposition of each of the polls. 23:58:26 enjoy your polltry 23:58:33 One more thing for the minutes from me is that the current VC spec requires contexts to work as JSON-LD :)