13:52:16 RRSAgent has joined #vcwg 13:52:20 logging to https://www.w3.org/2023/02/14-vcwg-irc 13:52:20 RRSAgent, make logs Public 13:52:21 please title this meeting ("meeting: ..."), ivan 13:53:01 Meeting: Verifiable Credentials Working Group F2F, 1st day 13:53:01 Date: 2023-02-14 13:53:01 Agenda: https://docs.google.com/presentation/d/128DHWSzVxPgAhB0mq-h23_iATnbVeA4Y-JhNLjpcXJE/edit?usp=sharing 13:53:01 chair: kristina, brent 13:53:01 ivan has changed the topic to: Meeting Agenda 2023-02-14: hhttps://docs.google.com/presentation/d/128DHWSzVxPgAhB0mq-h23_iATnbVeA4Y-JhNLjpcXJE/edit?usp=sharing 13:53:11 dlongley has joined #vcwg 13:58:27 present+ 13:59:41 manu_ has joined #vcwg 14:00:05 present+ identitywoman, kristina, oliver 14:00:09 present+ 14:00:10 present+ 14:00:50 present+ dlongley 14:02:40 decentralgabe has joined #vcwg 14:03:27 present+ andres 14:03:37 GeunHyung_Kim has joined #vcwg 14:03:43 present+ 14:04:13 msporny__ has joined #vcwg 14:06:25 present+ campbell 14:06:43 tzviya has joined #vcwg 14:07:17 gkellogg has joined #vcwg 14:08:11 kristina has joined #vcwg 14:08:19 present+ 14:10:57 BC has joined #vcwg 14:10:58 andres has joined #vcwg 14:11:34 BC has joined #vcwg 14:11:43 we have to make sure folks in miami aren't simulated 14:12:43 SamSmith has joined #vcwg 14:12:47 Identitywoman has joined #vcwg 14:12:47 present+ gabe 14:12:51 present+ Phil 14:12:51 oliver has joined #vcwg 14:12:54 present+ 14:13:04 Orie has joined #vcwg 14:13:11 present+ brent 14:13:14 present+ ? 14:13:14 Present+ 14:13:43 scribe+ 14:13:43 s/?// 14:13:49 brent: Welcome everyone! 14:13:58 present+ oliver 14:14:05 brent: We have a code of conduct, we're under the new patent policy 14:14:23 brent: here is today's agenda -- content types, holder binding, vc extension points, terminoilogy. 14:14:52 present+ 14:15:01 What is the link for the slides? 14:15:06 scribe+ msporny__ 14:15:13 brent: We're going to dinner around 5:30pm 14:15:14 mprorock has joined #vcwg 14:15:18 please add individual slidedecks to the master deck, as/when possible 14:15:24 https://docs.google.com/presentation/d/128DHWSzVxPgAhB0mq-h23_iATnbVeA4Y-JhNLjpcXJE/edit#slide=id.p1 14:15:24 present+ 14:15:26 Phil-ASU has joined #vcwg 14:15:28 holder binding conversation will be from 1:15pm no matter what - because we have ppl from NZ joining 14:15:41 brent: We need scribes, please sign up. 14:16:05 q+ to ask that individual slidedecks be added to the master deck, as/when possible 14:16:18 Paul_Dierich_GS1 has joined #vcwg 14:16:21 q? 14:16:27 can someone repost the slides link? 14:16:39 TallTed: Quick request, individual presentation decks added to master deck, please. 14:16:42 ack TallTed 14:16:42 TallTed, you wanted to ask that individual slidedecks be added to the master deck, as/when possible 14:17:10 JoeAndrieu has joined #vcwg 14:17:19 dwaite has joined #vcwg 14:17:19 selfissued has joined #vcwg 14:17:21 scribe+ 14:17:26 present+ 14:17:28 present+ 14:17:34 present+ 14:17:41 present+ JoeAndrieu 14:17:45 mkhraisha has joined #vcwg 14:17:49 present+ mahmoud 14:17:56 Phil_F has joined #vcwg 14:17:59 brent: Reminder, the VCWG mission is to make expressing, exchanging, and verifying credentials easier and more secure on the web. 14:18:07 present+ will 14:18:23 Will has joined #vcwg 14:18:56 gkellogg has joined #vcwg 14:19:17 brent: We have a list of normative deliverables and status... 14:19:42 present+ 14:20:07 brent: This is a lot of deliverables, the Technical Report Process applies to all of those items. 14:20:27 brent: The process goes from WD to CR to PR and then Recommendation. 14:20:48 brent: Once we address all issues we can keep going forward... 14:21:06 brent: Once we make substantive changes to CR, we have to start process again. 14:21:50 brent reviews the standard timing of our primary spec. 14:22:26 brent: timeline is to be done in may 2024, CR2 by Jan 2024, CR1 by Sept 2023, March 2023 feature freeze. 14:23:21 brent: You can change scope after you go into feature freeze -- we defined the scope. 14:23:33 brent: Doesn't mean we're done, we're done talking about what we're working on. 14:23:50 brent: One of the goals of the meeting is to have hard conversations about scope of work we think we can accomplish by end of charter. 14:24:41 mahmoud: Do all documents need to go through this process? 14:24:51 present+ markus 14:24:57 sam: What if we wanted to add a new document or a change/addition? 14:25:06 sam: What about vc-ac-dc? 14:25:57 brent: At this point, our WG process has to socialize for a week, then has to be a draft document, as a group -- in order to accept a work item, rough consensus and support from 3 organizations to bring it in as a work item. We will be pulling, from those orgs, the editors/authors of that spec. 14:25:59 q+ 14:26:11 sam: Assuming we have the resources to do the work? 14:26:33 brent: Then yes, it is (in theory) straightforward to bring a work item into the group, but as you saw, we have a lot of work items. 14:26:37 brent: For the main spec, feature freeze. 14:26:47 present+ sam 14:26:47 q- 14:26:50 brent: for other normative deliverables, a solid timeline for CR. 14:27:04 brent: For non-normative deliverables, a full understanding of the set of work for each. 14:27:44 brent: We could possibly recharter to work on items we don't get to.. 14:28:25 sam: So, you could have a main spec that gets done in 2024, but if you add items, you can extend charter? You can have flexibility in feature freeze. 14:28:45 brent: Feature freeze I'm talking about is for main spec... for every other normative deliverable, what's the plan for getting to CR. 14:29:24 brent: We have a lot of work going on in parallel, we need to have a good understanding for non-normative things. 14:29:35 brent: With that, introductions.... or questions. 14:29:36 Phil-ASU_ has joined #vcwg 14:29:36 q? 14:29:36 q? 14:29:48 Topic: Introductions 14:29:53 Orie has joined #vcwg 14:30:24 brent: We're going to do introductions now... the question that was always asked to the group is one that I will ask of you. 14:31:00 brent: Your name, who you're representing, your favorite breakfast cereal, if your feet could taste, what flavor would you want your socks to be. 14:32:13 brent: I'm brent zundel, representing Gen (Avast and Norton Lifelock), started at Evernym and here I am. My favorite breakfast cerial is honey bunches of ats ... would lik ea mint flavored sock. 14:33:09 kristina: Hi Kristina Yasuda, work for Microsoft, breakfast cereal -- crave (in europe chocolate biscuits)... favorite sock would be no smell socks. 14:33:34 oliver: Oliver Terbu, from Spruce, identity startup, favorite breakfast cereal (shakshuka), no opinion on socks. 14:34:18 Manu: Manu Sporny, Digital Bazaar, sardines and hummus, green apple socks. 14:34:37 samSmith: Sam Smith, work for startup studios, raisin bran and sock flavor lemon coconut. 14:34:54 Phil: Phil Fariller, GLEIF, lucky charms and blueberry socks.. 14:35:10 JoeAndrieu: Joe with Legenday, golden grams, mint green tea. 14:35:51 Przemek: Przemek, from Mastercard, cybersecurity and intelligence, cream of wheat with honey, roasted garlic saurkraut for socks. 14:36:10 KevinGriffin: Kevin Griffin, GLEIF, frosted cereal, bacon socks, please. 14:36:11 present+ przemek 14:36:17 gkellogg has joined #vcwg 14:36:47 present+ griffin 14:36:53 Shigeya: Shigeya Suzuki, KEIO University, bagel with cream cheese, no smelly socks. 14:37:25 Paul: Paul Dietrich, GS1, strawberry frosted pop tart, mint or citrus socks. 14:37:52 Will: Will Abramson, Legendary and Digital Contract Design (today), muselix, mountain spring water socks. 14:38:11 present+ PaulDietrich 14:38:24 MikeP: Mike Prorock, Mesur.io, southeast asia noodle dish, neutralizing socks. 14:38:32 brentz has joined #vcwg 14:38:43 Orie: Orie Steele, Transmute, DIDs and VCs, no cereal or socks. 14:38:59 Present+ 14:39:07 Gabe: Gabe from TBD/Block, french toast crunch, socks ginger to reduce nausea of everyday life. 14:39:33 DavidW: David Waite from Ping Identity, nice omlette, strawberry lemonade socks. 14:39:51 Mahmoud: Mahmoud, Mavennet, flat bread w/ cheese, chocolate socks. 14:40:33 MikeJ: Mike Jones from Microsoft, identity and security standards, crispix with fresh blueberries, if my feet could taste my socks need to be mango lassi. 14:41:27 andres: Andres from TBD/Blck, work with Gabe, arepa with cheese and fried egg, sock flavor key lime pie. 14:42:16 BrianCampbell: Bian Campbell, work with Ping, frosted mini wheats and recuse from foot tasting declarations. 14:42:29 DaveLongley: Dave Longley, Digital Bazaar, banana bread, chocolate socks. 14:42:52 DmitriZ: Dmitri Zagidulin, DCC, oatmeal or golden grams, neutral sock flavor. 14:43:27 GyhunHeungKim: Gyeun Heung Kim from GooMee, omlette and no sock options. 14:43:30 prefers not to talk unless necessary, still recovering... I am W3C staff contact, I mix all kinds of nuts for breakfast with youghourt, no idea about my feet 14:43:56 markus_sabadello has joined #vcwg 14:43:57 present+ dmitriz 14:44:04 present+ 14:44:06 dmitriz has joined #vcwg 14:44:16 s/GooMee/Gooroomee 14:44:21 Kaliya: Kaliya Young, IdentityWomanInBusiness, invited expert, favorite cereal grain free granola w/ yogurt, seaweed socks. 14:44:53 Markus: Markus Sabadello, Danube Tech in Vienna, favorite breakfast cereal corn flakes with milk, corn flake socks too 14:45:01 oh also I forgot to say the - who I'm with part -- Invited Expert, with MIT / Digital Credentials Consortium. (Also I think it's so ironic that MIT is not a W3C member :) ) 14:45:23 PhilLong: Phil Long, Arizona State, haitian blue coffee socks. 14:45:46 TallTed: Ted Thibodeau, Openlink Software, bacon eggs toasted english muffin, watermelon socks. 14:46:01 brentz: Thank you for tat, that was excellent. 14:46:21 Topic: Content Types 14:47:09 slides starting at: https://docs.google.com/presentation/d/128DHWSzVxPgAhB0mq-h23_iATnbVeA4Y-JhNLjpcXJE/edit#slide=id.g1482ccb90af_0_65 14:47:21 orie: We're going to be talking about content types and media types. 14:47:30 Q? 14:48:35 orie: Why do people say media type, conent type? Go read the links about what they are. Browsers care about this concept. It's a fundamental component of web architecture, conent type from web server. APIs protocols refer to these types, accept header, server will try to satisfy content types, lots of background here. 14:48:44 Jem has joined #vcwg 14:49:06 orie: Mozilla warning, browsers use the media type, not the file extension, to determine how to process the URL. If this is not correctly configured, browsers will misinterpret, files may be mishandled. 14:49:33 orie: We should be cautious to heed these warnings... 14:50:01 orie: Where are media types registered? Look at previous examples, excellent IETF mailing list for every type of media types. 14:50:10 Orie: You can learn a lot from those registrations. 14:50:53 Mozilla documentation errs. It refers to "MIME types" (I fixed this on the slide), and it should say `browsers *primarily* use the media type, *supplemented by* the file extension, to determine how to process the URL.` 14:51:06 orie: They typically register because they want to distinguish content... there is a registry, it has useful entries, large number of existing registry entries. 14:51:40 orie: As a technical recommendation, you can register -- in W3C you can see IANA considerations, that's where you register stuff (initiate the registration of stuff) 14:52:14 gkellogg has joined #vcwg 14:52:26 orie: A few that you might be familiar with... application/did+ld+json ... application/credential+ld+json ... usually, you only see one plus, suffixes that come at the end, an RFC making its way through IETF that talks about how to interpret pluses (suffixes). 14:52:40 q/ 14:52:42 q? 14:52:51 there's also https://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml 14:53:05 Structured Syntax Suffixes registry 14:53:29 time to register +ld 14:53:31 s/Phil: Phil Fariller/PhilFariller: Phil Fariller/ 14:53:44 present+ PhilFariller 14:54:07 orie: media types / content types -- looking at a few specifications, you should read them... in JSON Web Signatures, content type header parameter, in JWS, header and payload, one of the header parameters can be content type... secure CSV or JSON... declare cty using media type. 14:54:39 orie: oauth2 -- http endpoint using application/json -- might want to declare content type... might want to define HTTP 14:55:33 orie: JSON-LD Link Header, application/ld+json media type... specifying that media type has all context information and normative requirement for the document, constraining document in some way, normatively. 14:55:56 orie: One of the useful things about media types and content types and describe constraints... naming can be hard. 14:56:21 orie: media types are a good way of describing content and attributing content w/o getting tied up... 14:56:35 mikej: I'm excited about application/json because it does a lot of heavy lifting every day. 14:56:45 q? 14:57:39 orie: one of the other places you see media types show up is in APis... developers and consumers tend to think more about APIs... APIs are a great place to see real value wrt. media types and conent types. 14:57:43 gkellogg_ has joined #vcwg 14:58:09 s/conent/content/ 14:59:00 Zakim, who is here? 14:59:00 Present: TallTed, identitywoman, kristina, oliver, ivan, manu_, dlongley, andres, GeunHyung_Kim, campbell, gabe, Phil, decentralgabe, brent, ?, mprorock, selfissued, dwaite, 14:59:04 mkhraisha has joined #vcwg 14:59:04 ... shigeya, JoeAndrieu, mahmoud, will, markus, sam, przemek, griffin, PaulDietrich, brentz, dmitriz, markus_sabadello, PhilFariller 14:59:04 On IRC I see gkellogg_, Jem, dmitriz, brentz, Phil-ASU_, Will, selfissued, dwaite, JoeAndrieu, Paul_Dierich_GS1, mprorock, oliver, SamSmith, BC, andres, kristina, tzviya, manu_, 14:59:07 ... GeunHyung_Kim, decentralgabe, dlongley, RRSAgent, Zakim, TallTed, ivan, cel, saysaywhat, csarven, shigeya, hadleybeeman, bigbluehat, Dongwoo, stonematt, dlehn, npd, w3c_modbot, 14:59:07 ... stenr_, cel[h], ounfacdo, manu, bumblefudge, cel[m], rhiaro 14:59:24 orie: The swagger spec uses OAS now, rename was useful. Once you pick API shape, one endpoint HTTP endpoint, query parameters, required header parameters, post body arguments, you can define all of that with OAS 3. Valid response types... maybe endpoint returns JSON, maybe XML, maybe CSV, maybe you can ask... when you build an API, thinking about that is important... what will people request, what will they consume -- media types help here. 14:59:41 orie: Returning different content types for same resource can be helpful. 15:00:15 orie: Media tpe parameter is extra piece of information that can accompany a media type, text/html and charset is a parameter... utf-8 is a parameter. 15:00:22 gkellogg has joined #vcwg 15:01:37 orie: This is starting to get complicated... mozilla, content type... video/webm;codecs=vp8.0, browser API, inerested in video, concerned about video being processed consistently. Made use of the parameter, browsers can implement interfaces, implement different conent types, can manage complexity here -- nice text string to process can be valuable. 15:02:00 gkellogg has joined #vcwg 15:02:08 Present+ orie Will 15:02:33 orie: application/credential+ld+json -- here's where the debate starts... is `proof` allowed? We haven't registered this yet, it's proposal at present. 15:02:47 orie: We could change the proposal at any point. 15:03:03 mahmoud: What's the timeline on te proposal? 15:03:25 q+ 15:03:26 orie: This is in VC Data Model 2.0 -- has to go to CR first, that's timeline. It's up to us when it goes somewhere... 15:04:19 q+ 15:04:23 ack ivan 15:05:07 ivan: Formally speaking, W3C sends the request for media type when document is in CR, not before, right now nobody knows about this media type and won't know until we get to CR... if I'm still staff contact, this is the official process, I send it. 15:05:13 ack selfissued 15:05:21 q+ 15:05:30 +1 to Mike 15:05:42 +1 15:05:45 +1 can and does happen 15:06:08 mikej: One thing to add, it's good to send this when we're at CR because we can still make changes if IANA says we did someething wrong. What we would be asking for at CR is a provisional recommendation, it does appear and it appears as "termporary"... once we have a REC, at that point we send another request to IANA to update registration from provisional to permanent. 15:06:21 Brian Campbell 15:06:31 ack TallTed 15:06:47 +1 to TallTed 15:06:47 +1 ted 15:06:50 markus_sabadello has joined #vcwg 15:06:55 TallTed: One more wrinkle, because it has two plus signs at the right hand side, there is an RFC that is going through IETF, but indeterminate future, if it gets accepted then this media type is acceped, if it gets rejected 15:06:56 q+ 15:07:18 TallTed: then we'll have to figure that out at that point. 15:07:27 " ivan wonders who "BC" is" -> Brian Campbell 15:07:29 sorry 15:08:23 could't we use a specifc parameter to provide the extra information that a double plus content type provides without having to wait for RFC to allow double pluses? 15:08:25 scribe+ 15:08:28 ack manu_ 15:08:53 manu: rfc for multiple pluses is in good shape and getting ready for last call 15:08:54 q+ 15:09:05 q- 15:09:17 brent has joined #vcwg 15:09:33 orie: Here we have our request, one of the questions that we've been asking is whether proof is a valid/expected member of this content type. 15:09:59 FYI: https://datatracker.ietf.org/doc/draft-ietf-mediaman-suffixes/ 15:10:13 orie: What are the constraints, how can this be processed consistently, we want to be clear -- it's definitely alowed, or definitely disalloewd. 15:12:17 orie: There are content types where you might be more comfortable with membership being more optional, or where you might not be more comfortable. This PR was originally was very neutral, it didn't describe any constraints in our specification and we want to register a content type for it. We could say that proof is required, or we could say that proof is forbidden, what about "Verifiable Credential"? What will developers expect, what will browsers 15:12:17 expect, what will people hat write government policy read this section for this particular type, will they agree with the normative statements or will they be frustrated? 15:12:41 gkellogg has joined #vcwg 15:12:51 orie: We'll have to find consensus on these points, if you want to provide input, read #1014 -- it's long, it's getting longer, but the change set is not that large, but the threads can get long. 15:13:41 orie: This is a conversation about v2.0 and beyond, but there ar other pieces where we will talk abou tthe past. Tlaking about v1.1 vs. v2.0 15:13:42 q? 15:13:44 q? 15:14:49 A problem with "proof" is that in general cryptographically proofs cannot be embedded in the thing being proven. So a a multi-part structure like a JWT makes explicit what is being proven. An embedding trick where the proof value is empty and then the proof is substitued later and stripped to validate fails when there is more thatn one proof. 15:15:03 orie: on to application/credential-claims-set-1.1+json ... maybe we want .v1+json -- those are questions, this one is requested to be registered in a different technical recommendation in our group. 15:15:25 +1 15:16:20 q+ 15:16:21 mkhraisha has joined #vcwg 15:17:02 topic: Content Types 15:17:07 orie: I'm referring to the credential-claims-set-1.1, the interesting piece is "claims-set" == in example you can see members of a payload, there's sub, jti, iat, exp, nonce -- all of those are registered claim names.... the one important to us is 'vc' 15:17:46 https://www.iana.org/assignments/jwt/jwt.xhtml 15:18:06 q? 15:18:17 JWT Claims Set is defined by the JWT specification RFC 7519 15:18:28 orie: For different registry than media types, for JOSE -- JSON Web Tokens Claims registry. VC, the member of this payload, has a structure that looks like a credential, ignoring proof for a second, it looks like JSON-LD... the claim set in vc, has the same sort of thing. 15:19:05 The JWT Claims Registry is at https://www.iana.org/assignments/jwt/jwt.xhtml 15:19:11 orie: In v1.1, the vc member has to have an @context, that's what v1.1 says -- if you look at implementations, they will have a VC member, VC member, @context is required, that's what v1.1 says. 15:19:14 q? 15:19:20 ack selfissued 15:19:51 q+ 15:19:58 selfissued: Some background, this term claims set is defined by the JWT specification, RFC7519 and it's just a name for the JSON that is the body of a JSON Web Token, it's a JSON object with a bunch of claim names as the field names, so iss, typ, jti, those are the claims set claims. 15:20:05 ack mprorock 15:20:18 JWT Claims Set A JSON object that contains the claims conveyed by the JWT. 15:20:42 mprorock: There are some benefits for how claims sets are registered in -- JSON tends to get verbose, standardized way to say "these are things we say all the times"... 15:20:52 q+ 15:21:22 q+ 15:21:23 ack selfissued 15:21:28 orie: Thanks for the point about the shortness, there is text that says "We like short names for payload/header" ... but why, it could be that being more verbose would be more semantically unambigouous. 15:21:49 gkellogg has joined #vcwg 15:22:20 selfissued: The reason why, JWTs can be used in browser query strings, for various reasons, there are still browser URL length restrictions that are small... 2k, 4k, 8k... I fixed IE at one point, it's bigger than it used to be, you have systems truncating content. 15:22:37 orie: To make the token format, you can make a string encoding on top of another string encoding 15:22:42 selfissued: By a factor of 33% larger 15:23:20 ack SamSmith 15:23:21 orie: If these names get longer, those other names get longer, that's part of the design here. Part of the content type for the token themselves. After the break, we can see full token, token itself can be response from server, token can be encoded response. 15:23:54 q+ 15:23:56 SamSmith: For JSON Web Token, this would be the payload, adn then tunnelled within payload could have, content type, vc property could be JSON-LD formatted VC with proof included if proof is part of VC spec. 15:24:18 SamSmith: What you're proposing is using contnet type to indicate that you're tunnelling something else inside claim set? 15:25:06 orie: This particular registration request is also in VC-JWT today, to describe what we did in v1.1. We are working on v2.0, but we want to be able to refer to that object in v1.1 that concretely matches, shorer arguments about what we're doing in the future. 15:25:36 orie: Make it clear what our intenions are and what they should be in the future... VC format has external proof, you're only looking at payload, but there is a header/signature component. 15:25:46 SamSmith: This one is saying proof is externally attached. 15:25:48 orie: Yes.. 15:26:11 q+ to ask if the properties after @context are in the "vc" property 15:26:33 orie: There is something in v1.1 that states presense of proof... it warns that that could be confusing... if proof is embedded inside a member of a thing that has an external proof. 15:26:54 ack kristina 15:27:06 If a JWS is present, the digital signature refers either to the issuer of the verifiable credential, or in the case of a verifiable presentation, to the holder of the verifiable credential. The JWS proves that the iss of the JWT signed the contained JWT payload and therefore, the proof property can be omitted 15:27:20 https://w3c.github.io/vc-jwt/#jwt-encoding paragraph 2 15:27:21 kristina: found the statement, if JWS is present, digital signature applies to issuer... or VP ... is a holder. 15:27:41 https://w3c.github.io/vc-jwt/#jwt-encoding paragraph 3 15:27:43 q+ 15:27:44 If no JWS is present, a proof property MUST be provided. 15:27:44 orie: It says "can be omitted", doesn't say "MUST" be omitted. What we would interpret that as is proof is optional. 15:27:52 +1 one of the many issues in 1.1 15:27:58 q- 15:28:04 q+ 15:28:06 q+ 15:28:28 q+ to declare break 15:28:40 kristina: This has caused a lot of confusion, to clarify vc claim does not contain entire VC, it only contains properties defined in VC Data Model that didn't have mapping into original JWT claims, but VC only should contain stuff about credential subject. 15:28:50 q- 15:28:54 q+ orie 15:28:54 orie: At this point, we should read definition of credential and verifiable credential. 15:29:02 ack JoeAndrieu 15:29:02 JoeAndrieu, you wanted to ask if the properties after @context are in the "vc" property 15:29:38 JoeAndrieu: I don't know if this is substantive, is type after @context, are they scoped by VC? 15:29:43 i wrote some examples of the difference between "instead of/in addition to" that shows the claim set with "vc" here: https://github.com/w3c/vc-jwt/issues/42#issuecomment-1404054442 15:29:46 ack oliver 15:29:55 zakim, close the queue 15:29:55 ok, brent, the speaker queue is closed 15:30:02 q- 15:30:02 " a proof not based on digital signatures, such as Proof of Work" wow 15:30:34 yeah 15:30:47 some things that really need professional improvements in 2.0 15:31:02 ack orie 15:31:03 oliver: More background information, proof, why it can be omitted, to use it to express proofs other than what you can express w/ JWTs... you'd have VC JWT with proof with DI proof... those are things that are not great. Discussion over last few years, JWT claims repeated... instead of vs. in addition to -- intention was to focus on small size footprint ... use JWTs in query strings, that's why we decided to do that stuff. 15:31:11 q+ 15:31:34 credential A set of one or more claims made by an issuer. A verifiable credential is a tamper-evident credential that has authorship that can be cryptographically verified. Verifiable credentials can be used to build verifiable presentations, which can also be cryptographically verified. The claims in a credential can be about different subjects. 15:31:35 orie: This is probematic language in v1.1, definition of credential and verifiable credential uncomfortable and confusing to readers. 15:31:38 Phil_F has joined #vcwg 15:31:54 brent: A credential is a set of one or more claims made by an issuer. A verifiable credential is (reads from spec)... 15:31:54 can we please remove "authorship" from definition? it's weird.. 15:32:40 i want to find the time to do a verbiage / editorial pass soo soo badly 15:32:56 can we not user `vc` anymore in a vc-jwt... 15:33:01 in v2 i mean 15:33:15 orie: What I heard Kristina to say is: This isn't verifiable, but we use verifiable name for it... there is no cryptographic authorship, this is secured with an external proof, maybe this should be called credential because it has no proof, or call it creential cause it has an external proof, but confusing ... 15:33:17 +1 kristina 15:33:49 rrsagent, draft minutes 15:33:50 I have made the request to generate https://www.w3.org/2023/02/14-vcwg-minutes.html ivan 15:34:33 Awareness note: VCWG folks may want to pay special attention to recording and/or minutes of today's CCG meeting, Noon-1pm ET, focused on SB786 — CA Vital Records in Verifiable Credentials — https://www.w3.org/events/meetings/80a1023e-569b-4714-8fab-d1b84f2c3478/20230214T120000. 15:35:07 we come back in 15 min 15:35:14 10:50 local time 15:38:13 gkellogg has joined #vcwg 15:41:47 s/Gyeun Heung/Geun Hyung/ 15:44:07 gkellogg_ has joined #vcwg 15:45:22 gkellogg has joined #vcwg 15:49:55 gkellogg has joined #vcwg 15:51:26 selfissued has joined #vcwg 15:51:37 present+ 15:51:55 present+ 15:52:13 starting as soon as brent comes back 15:52:26 i think we lost audio 15:52:50 i just unmuted 15:52:50 ... and it's back! 15:52:54 ty 15:53:05 manu_ has joined #vcwg 15:53:41 zakim, open the queue 15:53:41 ok, brent, the speaker queue is open 15:54:59 scribe+ 15:55:05 q? 15:55:23 Orie: how many media types do we have defined right now? ... 0 in v1.1, 1 currently in the proposal 15:55:25 Paul_Dietrich_GS1 has joined #vcwg 15:56:32 Will has joined #vcwg 15:56:39 Orie: 1 defined so far. credential+ld+json ... slide from earlier. if we add new media types to the core data model we want to secure them. we need to describe how we do that. 15:57:16 Orie: have split out the 2 proof formats defined in 1.1. data integrity and vc jwt securing were defined in the same doc. in the current draft they're in separate documents 15:58:05 JoeAndrieu has joined #vcwg 15:58:12 Orie: pull request debate in 1014 talking about this. been talking about vc data integrity a lot. thread is about whether "proof" is a legal/allowed/required value for ld+proof+json 15:58:15 q+ to ask about the unsecured media type 15:58:41 Orie: underway in describing the relationship between the two. vc-jwt has a PR open. data integrity does not have a PR yet. 15:59:14 Orie: secured by data integrity, has the content type 'riding along with it' - different approaches. we are required to describe both cleanly for good impls 15:59:21 ack JoeAdrieu 15:59:24 q/ 15:59:26 q? 15:59:42 gkellogg_ has joined #vcwg 15:59:46 JoeAndrieu: at least a 3rd media type here we should understand as a group. media type we are securing, and two that are the secured version of them. the language here mushes them all together 16:00:16 present+ drummond 16:00:31 mprorock has joined #vcwg 16:00:37 Orie: the media type we're securing has the most consensus in the group. vc ld json. pull request 1014 is attempting to describe normative requirements for credential+ld+json. if we can gain consensus we can proceed to securing it. can be easy if the normative requirements are clear on how we do it 16:00:43 https://github.com/w3c/vc-data-model/pull/1014/ 16:00:43 q? 16:00:50 ack JoeAndrieu 16:00:50 JoeAndrieu, you wanted to ask about the unsecured media type 16:00:54 present+ mccown 16:02:04 Orie: new things! talking about v1.1 up until now. and core data model objects (credential). now, switching to talk about other concepts - proposals. pull request recently merged for vc+ld+jwt, but no FPWD for vc-jwt. there is plenty of time to object. 16:02:33 Orie: we talked about cty in the intro to media types. the content type of the payload. there is another - typ - which can be confusing. why do we have two? why cty and typ? typ is about the type of the token (the entire thing) - header, payload, signature 16:02:55 selfissued: typ is what you would put in a browser if you were to transmit 16:03:02 q+ 16:03:36 Orie: cty is about the payload alone, not header or signature 16:03:36 q+ 16:03:36 oliver has joined #vcwg 16:04:17 Orie: if you have typ do you need cty? PR #51 (merged?) is about typ being allowed. the proof property is constrained by the cty. is proof a member of the payload? see PR #1014 16:04:25 ack mprorock 16:04:41 PR 51 in vc-jwt, not merged yet 16:04:55 https://github.com/w3c/vc-jwt/pull/51 16:05:00 q+ 16:05:12 topic: Content Types (continued) 16:05:31 mprorock: a note on cty. referring to payloads is important for business logic processing. seeing this at IETF. #1014 - not whether a proof is allowed in the payload. whether it's allowed with credential+ld+json. or, should we say: if there is a proof embedded in the payload should we use a different cty to describe it, along with a different media type for the browser, etc. not saying whether you can have an embedded proof. 16:05:31 just the rules around it. 16:05:40 q+ to ask about what's the use case for embedded proof inside a jwt 16:05:51 Orie: that's right. spice from the first slide! 16:05:59 ack TallTed 16:06:40 TallTed: editing others slides. adding the / to the cty, for both cty and typ attrs. these values are shortened because people like to shorten things. specifically to delete "application/" from the beginning. it should be interpreted as if this were present. 16:06:54 TallTed: not the standard use of media types. will cause confusion if trying to use them now 16:07:10 smccown has joined #vcwg 16:07:11 Orie: can someone read the section that describes the removing of the application prefix? TallTed is right. 16:07:50 https://www.rfc-editor.org/rfc/rfc7515#section-4.1.9 16:08:00 dwaite: from RFC 7515 - section 4.1.10. - to keep messages compact, recommend you omit prefix when no other slash appears in the media type value. must treat it as if there application/ were prepended.. 16:08:15 ack manu_ 16:08:46 brentz has joined #vcwg 16:09:06 q? 16:09:10 q+ 16:09:13 q+ 16:09:13 manu_: part that's concerning. can't remember having to think this hard about other media types. general concern: all media types we're considering, how will they work combinatorially? lots to understand and learn. developers will get this wrong. 16:09:17 q+ 16:09:32 q+ 16:09:34 the key question is "what happens if devs get it wrong?" 16:09:40 manu_: "we will make important decisions around media types" -- slightly misguided. we will do our best for media types. devs will get it wrong, because it's difficult. what do we do then? 16:09:43 q+ to mention gzip 16:10:12 manu_: expecting to get something that's secured. and you don't, or maybe you do -- just checking the media type alone isn't sufficient. need to do other types of testing to see what you got and whether it's what you expect 16:10:17 qq+ orie 16:10:32 manu_: is there a combinatorial matrix? let's figure out a way to make it simple. misguided to say that media types alone will let us know whether something is secured or not 16:10:32 ack orie 16:10:32 orie, you wanted to react to manu_ 16:11:26 Orie: the point about "going into the thing to determine whether it's secured or not" is important. one thing dlongley has been saying...can have an intermediary processing a cty that has no ability to verify - just relay. all that it's able to do is to send along a cty. don't make any intermediary responsible for parsing. 16:11:35 mkhraisha has joined #vcwg 16:11:50 A warning about the practicalities of media types is in https://mimesniff.spec.whatwg.org/#introduction... 16:11:58 Orie: what manu_ is saying: be careful writing normative requirements that mandate parsing. envs that cannot dig in won't be able to handle normative requirements. an important part of considering this. 16:12:38 browser vendors probably won't parse any of these media types in the near future :) 16:12:40 Orie: second part: as a developer. don't like being told I'm going to make mistakes, even if I know that I will make them. here for simplicity as much as we can. remember the warning from browser vendors about handling ctys. browser vendors know that mistakes will be made. they try to warn, we should too 16:12:42 ack dmitriz 16:12:42 dmitriz, you wanted to ask about what's the use case for embedded proof inside a jwt 16:13:22 qq+ orie 16:13:33 ack orie 16:13:33 orie, you wanted to react to dmitriz 16:13:33 dmitriz: clarifying question about what mprorock said about #1014: what is the usefulness of embedding an embedded proof json-ld proof in a JWT? what's the benefit of a proofs section inside a jwt 16:13:48 ack mprorock 16:14:27 SamSmith has joined #vcwg 16:14:33 q+ 16:14:36 ok, so that's a great explanation, mprorock. but it does sort of point to the awkwardness of VC-JWT... (that it's a transform) 16:14:41 mprorock: there is a case I can foresee. not advocating for it. with a JWS you are not signing the same thing that you're signing with a data integrity proof. inherently signing two different things. with a JWS what you're signing is what you see (what the system sees at first glance). with a data integrity proof, signing over the semantics of the data in the credential -- signing a transformation, the nquads. different thing 16:14:45 +1 to mprorock 16:15:26 (n/m, I take back that comment. it's all transforms.) 16:15:42 mprorock: at a top level you can ask "is this data tampered with?" that's the use of JWS - the external signature. what's coming with the proof...let me run URDNA2015 and verify the signature. what that tells you is what is the intention of the semantics tied back to the vocba. was that itself modified? different than just signing the bytes 16:16:08 mprorock: is this possible? is it valuable in certain cases? 16:16:11 ack kristina 16:16:25 q+ 16:17:07 +1 kristina 16:17:10 kristina: 2 things - to manu_: agree we have a job to make it clear to readers which cty to use depending on which direction we want to go. to that extent, the current spec gives us those options already. heard a lot of feedback people want to do different things. codification is useful. maybe could be different than cty and typ. 16:17:17 +1 to there being value in both signing "the presentation bytes" and in signing "the semantic bytes" 16:17:28 1+ to point out what typ and cty are saying in this example 16:17:32 different use cases need one or perhaps even both 16:18:02 kristina: 2nd point - reacting to mprorock -- made a comment on the PR, explanation makes me thing if we want to sign JWT with an embedded proof it should be a separate media type. could be dangerous security wise 16:18:04 Isn't also a middle ground where the over the wire includes a schema that is additionally validated in addition to the signature. This is a different way o verifying the semantic intent. Not the same and maybe to a different degree but not devoid of samantic verification. 16:18:04 q- 16:18:10 mprorock: yes 16:18:18 ack dwaite 16:18:22 q+ to point out what typ and cty are saying in this example 16:18:22 ack selfissued 16:18:26 q+ orie 16:18:29 q+ on "no proof allowed on a credential, which is a subtype of VC"? 16:19:34 q+ to request specific concrete threats / problems for analysis before adding complexity of more types 16:19:49 +1 selfissued 16:20:06 selfissued: agree with kristina. appreciate what Orie, mprorock and others have advocated. starting to separate and cleanly advocate for things that are separated but distinct. in vc 1.0 spec we had the vcdm representation of content types. now we have a media type for that. also had 1 or more jwt claim sets for vc-jwts. depending on 'in addition to' or 'depends on' option - 2.0 now codifies that. delineation is important. th 16:20:06 ere will be sets that don't make sense - need to validate one's inputs always, that's always true 16:20:17 ack JoeAndrieu 16:20:17 JoeAndrieu, you wanted to mention gzip 16:20:19 q- later 16:20:20 selfissued: appreciate how differentiating things that are actually different has enabled us to make progress 16:20:36 q+ to note that there are things that are subtypes of one another. 16:20:43 q+ on whether using type parameters for media types for security has been considered 16:21:11 JoeAndrieu: something to be learned/looked at for how gzip is handled on the web. not clean either. media type could be gzip, could be content encoding as gzip. in a future universe would like an integrity type. do not have a way to do that yet. stuck with multiplicity. we also have verifiable presentations. have the same multiplicity there. 16:21:18 (to Joe's point -- I think Orie's earlier point was -- we /could/ specify integrity separately, as a Content Type param) 16:21:34 JoeAndrieu: ... however things get secured, will need to add it for both VCs and VPs. 16:21:40 ack SamSmith 16:22:30 maybe consider a media type parameter, like `Content-Type: application/vc+ld+jwt; integrity="whatever"` 16:22:44 SamSmith: to Gabe's comment, there can be a way of communicating other steps. not only does the signature need to validate, there needs to be validation against some schema. additional level of validation. can be useful to constrain semantics. need some discussion of how we can convey that 16:22:55 ack mprorock 16:22:55 mprorock, you wanted to point out what typ and cty are saying in this example 16:22:57 q+ to ask, why is the cty "credential+ld+json" vs "vc+ld+json"? 16:22:58 SamSmith: can say as a part of normative requirements. need to do validation for semantics/schema 16:23:00 I don't know if multiple parameters are viable... 16:23:06 @SamSmith - we do have that right now, no? with the credentialSchema claim? 16:23:39 q+ to ask about proposals so we can make some decisions 16:24:02 mprorock: I think manu_'s on to something important. here be dragons areas. let's be careful of what we're defining and how. what do we actually mean by typ and cty? what typ is saying -- we are expecting the overall body of the JWT to be a verifiable credential and have LD (as indicated) and expecting a JWT format. what the CTY is saying about the payload -- expecting it to be a credential with LD 16:25:10 @dmitriz But what are the normative rules for applying that credentialSchema claim. And should that be in the header metadata? 16:25:10 ... mprorock: this has been of the reasons I've been stubborn about 'when we start adding additional modifiers ...' many CVEs around this. openSSL had a typ confusion thing because x509 has badly handled this stuff. we should learn. even if it prevents us from doing some stuff. let's be explicit when there's a divergence. 16:25:53 mprorock: put out a couple of suggestions if this cty has an embedded proof...if we have that, let's indicate the payload has something special about it. it has been extended out and has an additional capability called 'proof' - today URDNA, tomorrow who knows 16:26:03 ack orie 16:26:05 q+ to posit that parameter type of integrity-type or similar 16:26:18 q- later 16:26:37 Orie: dmitriz asked the use case for proof being in claim set. mprorock answered, but want to repeat processing comment. can think of it as tunneling. I'm tunneling my embedded proof through the cty header. 16:27:08 @SamSmith - re that second question -- I think the content-type/media-type question is at a different layer than the schema. content type is at the browser or routing layer. and once it's correctly routed and parsed, then the schema kicks in 16:27:11 q? 16:27:48 ... Orie: e.g. constrained environment. it's a good thing, can forward content with different values for typ and cty. the concept of being allowed to tunnel one security format to another is a thing we see in the wild. should be careful of how that will be interpreted by browsers. allowing for tunneling could be a thing they like or don't - let's make a case for tunneling 16:28:09 ... Orie could be relevant to devices that are constrained, don't have libs to process, or just forwarders 16:28:09 +1 orie - valid use case - note that what is indicated if you embed a proof is that there is a higher order of what is signed that the issuer feels is important (in this case signing the semantics) 16:28:12 q+ 16:28:17 q+ 16:28:29 Orie: can close door to some use cases being affected if we do this 16:28:30 ack dlongley 16:28:30 dlongley, you wanted to request specific concrete threats / problems for analysis before adding complexity of more types 16:29:31 dlongley: tunneling is one of the cases, yes. have left many comments. let's only have as many media types as we need and not any more. always another place to draw a typ boundary. let's make sure the boundaries we draw solve concrete problems. e.g. places that use binary data. does not mean the same concerns will apply to a json format, parsing, or browser parsing 16:30:15 +1 dlongley -- only as many media types as necessary 16:30:22 q+ to add commentary of why an additional type 16:30:22 dlongley: if we have too many media types we can have more problems for ourselves. can lead to vulns. let's have concrete examples of threads/problems we can analyze to see if we can add more media types. then we should add them. let's not jump ahead and add all the types today. can cause problems 16:31:16 manu_: +1 to dave. trying to see what type of problems we're solving. yes, specific media types we want in this group. nobody's saying we shouldn't have them if they're paired with a good use case, paired with good security practices. that's good - no objections heard. objection -- let's create media type patterns. we could have 20-30 media types based on these patterns, that's where I get shaky. 16:31:18 q- 16:31:24 what is "media type pattern"..? 16:31:28 brent has joined #vcwg 16:31:34 q? 16:31:40 ack manu 16:31:40 manu_, you wanted to comment on "no proof allowed on a credential, which is a subtype of VC"? and to note that there are things that are subtypes of one another. 16:32:03 manu_: ... typ, yes. cty, yes. let's figure out if we want to add the word 'verifiable' in front of it. what do we want to do with the proof thing? is there anyone objecting to having the typ field (#51)? 16:32:18 `typ` field is recommended best practice these days for JWTs 16:32:36 @dmitriz I agree that schema validation is at a different layer than signature validation (which the content type is conveying) but schema validation is yet at a different layer than claims validation in the sense of semantic inference that URDNA-2015 is validating. that why its a middle ground. We should at least place it precisely in our definitions and not lump schema with somthing that is validating something else. 16:32:53 ... manu_: I expect that to happen (typ field). for a content type, that's a separate discussion. is it a subtype of credential? if it isn't there's a can of worms. see PR #1014. 16:33:44 ... manu_: just about #51 and #1014. let's take other proposals as they come. caveat: let's understand where we're going. let's not end up in a mess with 50+ media types with all sorts of normative language attached. next step: what should we do? make decisions about just 51 and 1014? 16:34:01 Orie: intention not to make any decisions during the f2f, just to inform 16:34:04 ack andres 16:34:04 andres, you wanted to comment on whether using type parameters for media types for security has been considered 16:34:06 brent: let's make decisions! 16:35:15 awesome question 16:35:24 andres: considerations for using the typ parameter for the media type defined that specifies how the credential is secured? anything that has 'verifiable' should have a typ param that specifies how it's secured. does this avoid the need for cty? as someone who's coming in relatively new. very different when you talk about a verifiable cred vs cred. verifiable = must have a proof whether embedded or external. would clarify a l 16:35:24 ot for devs 16:35:26 qq+ orie 16:35:34 ack orie 16:35:34 orie, you wanted to react to andres 16:36:26 ack mkhraisha 16:36:26 mkhraisha, you wanted to ask, why is the cty "credential+ld+json" vs "vc+ld+json"? 16:36:30 Orie: parameterization of media types..beginning said 'careful!' yes it's an option, can propose it on any of the open PRs. if we do that we need to describe these parameters in registration requests. less opaque. have to ask questions-is param present? what does it have? think if we can avoid parameterization we should 16:36:32 q+ to note that DI and JWT operate in different philosophies (external vs. embedded are different philosophies) -- there will be no +data-integrity and there might be multiple embedded proof types. 16:37:05 mkhraisha: to understand...the cty saying credential+ld+json indicates to me that the object vc will or will not have a proof (determined on #1014), if not a proof, will know whether the object is signed or not based on the typ? 16:37:40 Orie: current spec has a section called 'proofs' which says proofs can be embedded or external. one of the most confusing parts - with media types, can have a media type with an external proof. content wouldn't have a proof. 16:38:14 all of this discussion is only really in the context of JWTs 16:38:32 ... Orie: jwt uses external proofs. the type vc+ld+jwt indicates the presence of an external proof. the cty param credential+ld+json (let's pretend it's verifiable+credential+ld+json), proof would be in the payload. we won't know until we constrain the payload 16:38:33 typ isn't really a thing you can assume exist in other presentation or exchange methods 16:38:49 ack JoeAndrieu 16:38:49 JoeAndrieu, you wanted to posit that parameter type of integrity-type or similar 16:38:52 mkhraisha: when I'm processing vc+ld+jwt am I expected to process two signatures? 16:38:55 Orie: that's the warning! 16:40:03 JoeAndrieu: advocate for parameter use. have an underlying data model which is being delivered. if we had an integrity type in the header I'd be arguing for using that. the integrity mechanism feels like a parameter to me. if we have two media types they don't have to be related at all. part of the confusion is about tunneling. the idea that you can tunnel is something we should not encourage - have to check different proofs 16:40:11 ... JoeAndrieu: checking multiple = creating problems 16:40:14 ack brent 16:40:14 brentz, you wanted to ask about proposals so we can make some decisions 16:40:34 brentz: what decisions do we want to make here? PR #1014 proposes to say proof is not included, right? 16:40:54 Orie: yes, dlongley and I had a discussion. he suggested proof is allowed in credential+ld+json. my original intention was to forbid that from being possible. 16:40:58 that's correct, a verifiable credential is also a credential, it is a subclass of it. 16:41:18 not to mention that `proof` may have many different kinds of proofs in it and so on. 16:41:43 q? 16:41:51 ... Orie: merged that since it was within my original intention. merging intentions into PR does not mean consensus! there is currently no consensus on #1014. most accurately captured by whether the cty can have a proof in it. can make that decision today 16:41:55 q+ 16:42:08 brent: also a decision to be made for #51? 16:42:20 q+ to say it's also about naming the unverifiable credential as a transportable thing 16:42:29 Orie: yes, for #51 we are requesting the registration for typ parameter in vc-jwt. it is JWT specific. #1014 is core data model specific 16:42:53 for everyone here: is a square a rectangle? if you have a square, should you be able to say it's also a rectangle so you can give it to a rectangle processor or not? 16:42:57 brent: in addition to those two decisions, what other proposals could/should be on the table for the group for the next 30m? 16:43:11 +1 to dlongley 16:43:24 Orie: other proposal: application/vc+ld+cwt. 16:43:38 ack selfissued 16:43:45 q+ selfissued 16:43:48 ack mprorock 16:43:48 mprorock, you wanted to add commentary of why an additional type 16:43:55 dlongley: we get to decide if it makes sense if squares are rectangles in this case :) 16:43:59 I would propose adding a media type: `application/vc+ld+json;proof={embedded,jwt,cwt}` 16:44:24 decentralgabe: they already are :) ... we'd have to change the VCDM. ... and it would be very confusing to decide the opposite. 16:44:33 @andres - nice, +1 16:44:45 dlongley -- Squares are a subclass/subtype of rectangles. All squares are rectangles. Many rectangles are not squares. We should be able to declare *and/or* infer multiple types. 16:44:55 +1 to TallTed 16:45:30 mprorock: assumption from devs coming in that you're just living in a JOSE/COSE world. but have two different ways of exchanging info beyond that. if I as an issuer send this, if I believe there's a high degree of value in the embedded proof then I should signal it. 16:45:55 q+ 16:46:20 ... mprorock: when we say that cty (payload) and just see credential-json, assumption is not that I need to do additional verification steps. don't want to put us in a position where a developer encounters this and has to do multiple verifications (semantics and bytes modifications) 16:46:58 ... mprorock: want to be very clear about the intentions here. if I see another proof inside it's another bit of bytes that I'm ignoring. the problem is that we've created a situation where that proof means something to someone and something else to someone else -- now we've created confusion 16:47:10 q+ to say some people just work with rectangles, not squares ... and to say that everyone ignored JSON properties they don't care about or understand already that is the model 16:47:52 ... mprorock: this kind of confusion is what we'll get into. get into weird stuff 16:47:56 ack manu_ 16:47:56 manu_, you wanted to note that DI and JWT operate in different philosophies (external vs. embedded are different philosophies) -- there will be no +data-integrity and there might 16:48:00 ... be multiple embedded proof types. 16:48:54 manu_: the other thing at play -- we have two different philosophies. the JWT philosophy, and embedded proof, and they don't make the same decisions. for media types let me propose we only have two media types forever: credential+ld+ and verifiable+credential+ld+ 16:49:24 i think this is the current situation: https://hackmd.io/Q8EOfbzYTZK_jHH-BJcfKA?view 16:49:31 wrt all of the media types proposed 16:49:46 ... manu_: specifically not saying it has "proof" because that's just how we do it today. I'm concerned about us fixating on whether proof is there or not, we should focus on whether there's an embedded proof or not. from the DI side there will not be a +di for a while. we won't make that decision any time soon. will wait for impl feedback. 16:50:14 ... manu_: from the LD side, just need those two media types: credential+ld+ and verifiable+credential+ld+ -- think dlongley disagrees with me on this and thinks we just need 1. everything else is JWT stuff 16:50:26 ack dwaite 16:50:27 ... manu_: the two coming in contact is causing confusion 16:51:22 dwaite: it is a little bit weird. the way things are structured at the JSON level are not how they're processed at the LD level, since being an RDF graph. a lot closer than you think. in my opinion, we've defined multiple proofs only in the context of the proof parameter can we have multiple values 16:51:24 @SamSmith - so if I'm understanding correctly what you're saying earlier, you're saying 1) specs should have normative language about the credentialSchema property. (and I think they do, at least for json schema. and if it's not clear, we should fix it). and 2) you'd like to see schema treated at basically the same layer as the Media Type? (to help routing/parsing?) - which I can sort of see the argument for. But then it introduces yet a third 16:51:24 type-related property, and we already have 2, which is too many :) 16:52:03 ... dwaite: the semantics of a data integrity proof and a proof inside a JWT are quite different. e.g. protecting someone else's proof with my own (today it is chains). the only interpretation I can think of is that the proofs are independent. if there are multiple, choose between them. any intermediary could remove proofs, and have no way to know that happened 16:52:49 ... dwaite: if someone gave me the inside of the message w/o the wrapping JWT, what's the interpretation? people may go with the alternative and that's not right. if they are proof chaining, I could trick people to accept a smaller part of the chain. semantics of multiple proofs that haven't been defined 16:52:51 ack JoeAndrieu 16:52:51 JoeAndrieu, you wanted to say it's also about naming the unverifiable credential as a transportable thing 16:53:38 JoeAndrieu: the parameter still resonates with me. not talking yet about the API used to send a proto-vc (unsigned) to be signed by another component. to me that is credential+ld+json, parameters used to specify the type of proof embedded in the VC, instead of the VC embedded in the proof 16:53:41 +1 JoeAndrieu 16:53:52 q+ parameter concern 16:54:05 q- param 16:54:05 q+ mprorock 16:54:12 q- concern 16:54:52 kristina: reviewing document posted above ( https://hackmd.io/Q8EOfbzYTZK_jHH-BJcfKA?view) 16:55:38 gkellogg has joined #vcwg 16:55:54 Orie: do not have any merges for typ in the core data model just yet 16:56:14 kristina: Manu's proposal in typ not cty 16:56:15 gkellogg has joined #vcwg 16:56:34 ack selfissued 16:56:40 samsmith__ has joined #vcwg 16:56:49 q 16:56:57 Phil_F has joined #vcwg 16:57:15 selfissued: we can also provide guidance in the spec on the use of credential+ld data type if used with an external proof--must not also contain an internal proof. whereas; if used within a context with internal proofs it may contain one. that would be OK with me. 16:57:15 q+ 16:57:44 ... selfissued: coming at this from how you normally process json. can add a new member and processing won't break. it's fine to write down intended usage. will add this to #1014 16:57:49 brent: 15m before lunch! 16:57:55 q 16:58:18 Orie: [new slide - 25] Pull #51 in vc-jwt has both vc+ld+cwt and vc+ld+jwt 16:58:53 q+ to note there is no such thing as "+ld+jwt/cwt" <-- but this is a minor detail we can deal w/ 16:59:36 ack andres 16:59:43 ... Orie: interesting part.. cwt varies on the suffix, the typ does no. the core data model could say that cty has a proof, but securing could say they can't - they can content. we don't want that. noting that typ registration is in vc-jwt, cty usage is defined in vc-jwt, but in the core data model 17:00:11 q+ to throw wrenches 17:00:24 ack dlongley 17:00:24 dlongley, you wanted to say some people just work with rectangles, not squares ... and to say that everyone ignored JSON properties they don't care about or understand already that 17:00:28 ... is the model 17:00:36 andres: concrete proposal to make sure there are parameters. not just add credential+ld+json but specify how it is proved, e.g. ?proof=[jwt, cwt, etc.]. similar to what Joe was saying / and adding to Manu was saying 17:01:35 FWIW, I added a concrete parameter suggestion in the PR https://github.com/w3c/vc-data-model/pull/1014#issuecomment-1430076799 17:01:52 dlongley: every VC is a C. every square is a rectangle. already have a model where you look at JSON properties - you look at the ones you understand, ignore the ones you don't. also understand whether they care about these proofs/properties. if you don't care - fine - does not mean a sender should explicitly remove it, should not need to explicitly remove it because it's there. providing guidance around processing is fine. sh 17:01:53 ould not be too prescriptive. can harm legitimate use cases and violate expectations around subclasses 17:02:04 ack thanks joe, nice! 17:02:16 q+ to ask what are the downsides of saying "credential+ld+json" is unsecured and "vc+ld+json" is secured? 17:02:24 q+ to say we're banning something -- that needs a use case 17:02:28 +1 Use Cases -> Requirements -> satisfy those requirements 17:03:00 -1 it's not a concrete use case, it does not apply, this is not binary data 17:03:09 ack mprorock 17:03:09 Orie: responding to dlongley. let's surface legitimate use cases. let's make sure use cases are driving our spec development. without these normative statements, we have trouble satisfying. tunneling is a real use case. "type confusion attack" mprorock mentioned. is that a concrete use case for forbidding proof being in the payload? 17:03:21 s/it's not/the openssl and x.509 CVEs are not/ 17:04:18 zakim, close the queue 17:04:18 ok, brent, the speaker queue is closed 17:04:24 mprorock: want to call out. parameterization - have experience around media stream handling. there is a parameterization to be had, maybe not in 2.0 but in future versions of LD. how do we indicate at the header layer what signature am I expecting? same notion of parameterization in cryptography. 17:04:48 ... mprorock: credential+ld+json = what goes in to get signed. verifiable is what comes out. <-- that notion is important to me. rolls back into type inheritance question 17:05:30 ack samsmith__ 17:05:31 ... mprorock: have a dog and have a tiger. fine to put a leash on a dog, but put a leash on a tiger and you get bit. if we don't have good guidance on things like embedded proofs, how do we know what takes precedence? someone will think they have a whole, but just have a part. need to avoid this. 17:06:07 manjaroi3 has joined #vcwg 17:06:25 samsmith__: one use case not seen discussed - prevalent in business/legal world: endorsements. have a party create something. other parties lend credibility via endorsements. can have threshold structures for issuance. can also have threshold structures for receiving. should support things that are really prevalent in the business world 17:06:51 samsmith__: receipting is a type of stacked proof. missing an important use case by not explicitly dealing with receipts/endorsements as a proof mechanism. have most of the elements needed with what we're talking about 17:07:02 q? 17:07:09 ack manu_ 17:07:09 manu_, you wanted to note there is no such thing as "+ld+jwt/cwt" <-- but this is a minor detail we can deal w/ 17:07:45 manu_: clarification there is no +ld media type. does not exist. it is only ld+json. would need to figure out something... 17:08:49 ... manu_: there is a media type suffixes discussion. how do you unwrap all that stuff. there is a spec that exists to unwrap it all. can be complex to go that way. if we have crazy permutations and need to read normative statements, we may want to go look at suffixes. we fail if we hit that level of complexity. need to figure out what +ld turns into. maybe just vc+jwt 17:09:28 brent: Dave mentioned squares and rectangles. Let's talk about the accurate labeling of squares and rectangles. 17:10:08 q? 17:10:10 ... brent: how bad would it be if credential+ld+json remained how it is (could have a proof, or not). but the typ field one could add specificity. e.g. say you're not allowed to secure the typ with a proof section 17:10:14 ack brent 17:10:14 brent, you wanted to throw wrenches 17:10:22 ack mkhraisha 17:10:22 mkhraisha, you wanted to ask what are the downsides of saying "credential+ld+json" is unsecured and "vc+ld+json" is secured? 17:10:59 brent_ has joined #vcwg 17:11:00 mkhraisha: had a similar question. if we separate credential+ld+json to state there will be no proof and have vc+ld+json and say there will be a proof, will allow us, when we use the cty field, if the typ field says ld+jwt, can say process the internal signature as well or do not 17:11:12 q+ to speak to different issuers is legit, tunneling bad 17:11:15 +1 that the processing rules for vc+ld+jwt could say you may not have the proof is fine / or define whatever 17:11:19 q+ to start with softer language and tighten it up over time? 17:11:23 q? 17:11:33 ... mkhraisha: can make it very clear when I receive a vc+ld+json I should process a proof. normative requirement would be straightforward. allows us on the JWT side to say I care or don't. 17:11:40 ... mkhraisha: what are the downsides to this approach? 17:11:42 ack dlongley 17:11:42 dlongley, you wanted to say we're banning something -- that needs a use case 17:12:04 dlongley: if we're deciding to add a prohibitive statement let's be clear about what problem it's solving with a concrete use case. 17:12:22 q+ to state the (at least "a") problem 17:12:42 ... dlongley: what brent suggested would be a good approach. if proofs are not allowed in this case, throw an err. may not be the best idea, but do not encroach on the media type and do not violate the shape problem 17:14:21 so did somebody propose media type param approach, for proofs? 17:14:55 q+ to speak to different issuers is legit, tunneling bad 17:15:04 q+ to speak to different issuers is legit, tunneling bad 17:15:04 zakim, open the queue 17:15:05 q+ to state the problem 17:15:05 ok, brentz, the speaker queue is open 17:15:08 q+ to speak to different issuers is legit, tunneling bad 17:15:23 q+ to note softer language to start? 17:16:18 Orie: unbounded number of content types that are relevant to software development. that's why cty is liked. can treat as opaque bytes with a cty that informs the strucutre 17:17:05 Orie: in scitt if you're talking about a claim (which we call a VC) there would be a helm chart JSON in both places, but without a typ parameter 17:17:23 ... Orie: this structure isn't out of nowhere. others are talking about doing this 17:17:24 first here means ctyp second here means right side of the screen 17:18:35 ... Orie: dlongley asking for concrete use cases. proof being present in a credential. mprorock has said openSSL type confusion as an example. another place it could be a problem: if the @context returns different content than what it was when the canonicalized proof was created, the outer external proof will verify, the inner won't until the URL in the context change(s/d) 17:18:48 ... Orie: having both present leads to a behavior with mixed verifiability 17:18:56 ack mprorock 17:18:56 mprorock, you wanted to state the problem 17:18:58 q+ 17:19:06 s/... Orie:/.../ 17:20:12 gkellogg has joined #vcwg 17:20:34 mprorock: two concrete problems: one - what Orie mentioned. second -- crawling and parsing massive amounts of data...what went into models...could be cases where I want to embed different types of proofs. don't want that knowledge to be confused for any of my users. e.g. for web archive, need to maintain the state of the internet at different times. how we begin to do this? 17:21:15 ... mprorock: work here and at scitt will inform how we do this stuff. only adding when 'absolutely necessary' - what manu_ is getting at. let's not end up with 50+. would be simpler if everything had typ, doesn't though. that's why for scitt switching over cty is important, especially if it contains sec parameters. 17:21:16 ack JoeAndrieu 17:21:16 JoeAndrieu, you wanted to speak to different issuers is legit, tunneling bad 17:21:43 JoeAndrieu: there is an unstated presumption that's conflating the signature on a JWT with a signature on a proof. no reason it needs to be on the same issuer. 17:21:51 q+ to talk about tunneling 17:22:04 ack manu_ 17:22:04 manu_, you wanted to note softer language to start? 17:22:53 manu_: going back to what selfissued said. maybe we can add language to not outright forbid in the base class. start out with softer language in the beginning - not outright "don't do x" - then we can either go to "now it's forbidden" or we realize the guidance goes against real use cases. 17:23:06 why can't we prohibit, and wait until people tell us they need it? 17:23:22 ... where the JWT stuff can be very explicit: do not do it. the base spec can say "this is what people are expecting" . see VC-JWT for more information on this 17:23:22 q+ to ask a manu clarify question 17:23:25 q+ to say you have to know a priori what VCs you care about and whether you care about presentation byte or semantic byte signing... you decide you're verifying *or* you abstract that piece and try to verify everything and return what was verified and what wasn't / and any problems 17:23:26 ack samsmith__ 17:23:35 +1 to manu's approach 17:24:18 samsmith__: echo Orie's statement. if I sign a receipt. if someone purchases from me, it's signed, it has a proof. I give a receipt on the proof that I sign, referencing what they sign. liability on issuing receipt is on me. 17:25:06 ack decentralgabe 17:25:06 decentralgabe, you wanted to talk about tunneling 17:25:12 ... don't have to impose on receipter any requirements - already have the liability. different from assumptions in other parts of the web. receipting is a powerful use case. what does it mean to sign something as a proof? legal construct not just cryptographic. 17:25:13 scribe+ 17:25:55 +1 ivan very differnt 17:25:55 ack mprorock 17:25:55 mprorock, you wanted to ask a manu clarify question 17:25:55 decentralgabe: The use case for tunnelling, at TBD, transport credentials over DWNs. Use cases on status list, different signature methods, blob might be signed as a VC itself, might have many different types -- tunnelling is real. 17:26:03 scribe+ 17:26:10 why would you send those statusList VCs in a VC(?) tho 17:26:13 is it verifiable+credentials+ld+json or verifiable-credentials+ld+json ? These are _very_ different 17:26:28 it is vc+ld_json 17:26:36 it is vc+ld+son 17:26:39 in the spec rn - verifiable-credentials+ld+json 17:26:48 +1 kristina 17:26:56 i mean `verifiable-credential+jwt` 17:27:02 mprorock: different between verifiable+credential and verifiable/credential 17:27:04 q+ orie 17:27:08 ... should get agreement 17:27:11 ack dlongley 17:27:11 dlongley, you wanted to say you have to know a priori what VCs you care about and whether you care about presentation byte or semantic byte signing... you decide you're verifying 17:27:15 ... *or* you abstract that piece and try to verify everything and return what was verified and what wasn't / and any problems 17:27:37 I am talking about jwt, but abyt, say, cty 17:27:55 manjaroi3 has joined #vcwg 17:28:01 sure on jwt space - but then what about things like vc-api and "what am i asking to sign and what am i returning" 17:28:23 dlongley: need to know what you care about a priori. need to decide what you're verifying and make decisions there. let's make sure we know where the knowledge is coming from. verifier should know ahead of time what it's looking for and willing to verify 17:28:26 q? 17:28:28 ack orie 17:28:32 that also implies that we may not want this stuff in the browser 17:28:35 i certainly do 17:28:46 s/abyt/about/ 17:29:37 Orie: queued to comment on verifiable+credential or verifiable-credential - have been comments on #1014. if the dash were changed to a plus it would say there's a direct relation to credential...only a content type when ld+json, different than verifiable-credential+otherstuff. what Ted said: verifiable-credential and credential are at the same level 17:30:07 ... don't have to be related at all. they have a repeated word, but it is misleading. application/foo and application/baz, normative constraints on both. see and think they're the same structure, but they don't have to be at all 17:30:13 q? 17:30:19 q+ to note browser side 17:30:19 ... verifiable-credential and credential can be wildly different in ways that are horrendously confusing 17:30:22 gkellogg has joined #vcwg 17:30:39 ... they can be related...or we can explicitly not register verifiable-credential because it's confusing. review comments on #1014! 17:30:47 ack mprorock 17:30:47 mprorock, you wanted to note browser side 17:31:22 q+ 17:31:26 mprorock: just do this in 'vc-jwts': if this is a W3C....we eat this up in the browser. we need to think about what I, as a browser, see application/??? - do I know how to verify it? 17:31:32 zakim, close the queue 17:31:32 ok, kristina, the speaker queue is closed 17:32:10 ... especially re: eu product passes. coming up more and more. must be very well defined at the core data model. say one is the input (goes and gets signed) the other is the output (signed thing). if we are not careful we will end up with problems down the line. Mozilla, Google, Apple, etc will object if we do not give them clear direction of what to do with this data when they get it 17:32:20 ack manu_ 17:32:22 @decentralgabe are you sending those in a VP or a VC? 17:32:27 -1 to everything is Mike saying :) ... credential+ld+json will just not have any proofs processed by default by browsers, the end :) 17:32:46 if in a VP, no need for tunneling, no? 17:33:00 each VC is signed using its own way, and VP is signed using one way 17:33:06 gkellogg_ has joined #vcwg 17:33:19 @manu - do you think Google et al will support using media type parameters, for proof types? 17:33:21 manu_: all vendors support application/ld+json. tell vendors do things as you've always been doing. 17:33:53 don't VPs need their own media types? 17:34:33 yes, probably :) 17:34:47 scribe- 17:35:09 rrsagent, draft minutes 17:35:11 I have made the request to generate https://www.w3.org/2023/02/14-vcwg-minutes.html ivan 17:35:51 what time will meeting resume after lunch? 17:36:27 appears to be 13:25 ET 17:36:47 thanks! 17:37:59 gkellogg has joined #vcwg 17:39:26 gkellogg has joined #vcwg 17:55:27 brian has joined #vcwg 18:07:21 gkellogg has joined #vcwg 18:15:58 DavidC has joined #vcwg 18:16:08 present+ 18:26:10 gkellogg has joined #vcwg 18:31:57 oliver has joined #vcwg 18:32:41 manu_ has joined #vcwg 18:33:02 dwaite has joined #vcwg 18:33:20 SamSmith has joined #vcwg 18:33:25 JoeAndrieu has joined #vcwg 18:33:32 Will has joined #vcwg 18:33:41 Phil_F has joined #vcwg 18:33:52 brent has joined #vcwg 18:34:05 identitywoman has joined #vcwg 18:34:13 mprorock has joined #vcwg 18:34:20 decentralgabe has joined #vcwg 18:34:50 we should take a page from Evin McMullen's "fun" attitude and make verifiable valentines :) 18:35:07 :) 18:35:16 scribe+ 18:35:27 Orie has joined #vcwg 18:35:46 oliver: Session about holder binding 18:36:02 ... multiple issues about this in vcdm 18:36:22 ... slides by oliver and DavidC. Don't both agree fully 18:36:25 selfissued has joined #vcwg 18:36:34 ... slides note agreement 18:37:04 present+ 18:37:11 Paul_Dietrich_GS1 has joined #vcwg 18:37:14 q+ to say we should refine the problem statement to rule out the collusion case 18:37:32 kristina has joined #vcwg 18:37:38 present+ 18:37:40 q? 18:37:40 ... problem statement how can verifier trust that the entity that presents a VP is entitled to present the embedded VCs and they did not simply get a copy 18:38:06 gkellogg has joined #vcwg 18:38:15 zakim, open the queue 18:38:15 ok, kristina, the speaker queue is open 18:38:38 ... second prob statement in slide from oliver relates to confirming the VP. 18:38:45 q+ to say we should refine the problem statement to rule out the collusion case 18:39:09 ... slides will clarify this prob statement 18:39:18 manjaroi3 has joined #vcwg 18:39:27 q? 18:39:37 ... oliver to present before taking Qs 18:39:47 Why not just have a metadate field labeld "issuedTo" whose value is a cryptonym (cryptographically derived identifier) with similar security properties for the identifier of the "issuedBy" 18:39:58 ... assumptions - issuer should know who the verifier is 18:40:15 s/should/should never/ 18:40:29 SamSmith: that is one of the ideas being thrown about as a possible solution / partial solution, to my knowledge 18:40:34 ... isuer may attempt to control the use of VC through termsOfUse 18:40:52 ... but binding is a claim made by issuer about subject 18:41:19 ... isuers are trusted, if not then VCs should not be accepted by verifier 18:41:32 q+ 18:41:43 ... meaning if issuer includes confirmation methods in VC the verifier can trust these 18:42:33 ... evidence property doesn't cover this use case 18:42:33 dmitriz has joined #vcwg 18:42:33 gkellogg_ has joined #vcwg 18:43:20 ... confirmation method definition on slide 31 of the deck 18:43:51 @will my point is that the subject is not metadata, the subject of a credential need not be the "issuedTo" the "issuedTo" is a permitted presented designated by the "issuedBy" that may be proven independent of the subject. If the subject happens to be the same identifier as the "issuedTo" then you have also binding to the subject but there are many use cases where this should not be that saem. 18:43:51 ... a conf method could be a cryptographic identifier or key 18:44:41 ... trying to come up with standard mechanism for this 18:45:25 ... feedback from ccg is that any property of subject of VC could be used to determine if presenter is subject of presented VC 18:46:11 ... though in certain cases e.g. zkp bases there aren't many useful properties in credSubject 18:46:20 gkellog__ has joined #vcwg 18:46:37 ... issuer does not need to tell verifier what properties to use. Up to the verifier 18:46:46 q- 18:47:33 ... need mechanisms to make the verifiers life easier 18:48:15 brentz has joined #vcwg 18:48:22 ... RWOT paper on holder binding. Although became clear term is confusing 18:48:49 ... subject not always holder 18:48:55 q? 18:48:59 ... holder binding misleading as used in different contexts 18:49:08 ... rwot paper proposed identifier binding term 18:49:15 +1 that "identifier binding" is better than "holder binding" 18:49:31 (maybe still not "the best" possible name, but better) 18:49:32 Phil_F has joined #vcwg 18:50:01 using "issuedTo" as metadata not embedded in the subject claims can remove the fuzziness inherent with claims. In many cases we don't want the fuzziness. Clearly not having an issuedTo could mean we want the fuzziness. But if present the issuedTo puts the issuedTo on an elevated security basis potentially equivalent to the issuedBy 18:50:30 q+ 18:50:33 ... Definition of identifier binding found in slide 34 18:50:48 q? 18:51:15 ... paper uses a simple use case 18:51:48 ... more realistic might be from the EU digital wallet initiative. e.g. esim, online prescriptions etc 18:52:28 gkellogg has joined #vcwg 18:52:50 ... paper use case looks at three variations of a course offering. Remote async, remote sync and inperson 18:53:34 manu_: is the trevor use case a malicious one 18:53:50 oliver: no, in some cases gov want to enable "friendly fraud" 18:54:03 ... looking at the fully remote scenario first 18:54:39 q+ 18:55:08 ... one cred "second order logic" contains only the information that some identifier passed the course Second Order logic. That is it 18:55:19 ... on its own, not that useful 18:55:38 This seems like a weak form of Guardianship. If we allow a credential that entitles a third party to enroll on my behalf then Bob can clearly state his security requirements that either the party must enroll themselves or they must designate someone to enroll on their behalf. 18:55:51 ... might add some pii to the credential subject. e.g. name 18:56:32 ... possible to use this VC for in person verification. e.g.alice brings passport to course 18:56:41 ... but looking at fully remote usecase 18:56:52 q- 18:57:21 ... Alice could prove control over a key, and this can be included into the VC 18:57:59 ... could add publicKey or VM property to VC. But not clear to verifier how to interpret this 18:58:08 possible alternative / bikeshedding "identifier binding" definition: identifying an entity using an identifier that is associated with a secret value, whereby a cryptographic operation that depends on the secret can be performed and checked against the identifier 18:58:11 q+ 18:58:22 q+ to note verification methods are a part of Data Integrity and are a part of "controller documents"... 18:58:30 ... propose new property - binding in paper 18:58:35 ... can bikeshed term later 18:58:44 ... I like confirmationMethod 18:59:49 ... this property makes clear the semantics 19:00:11 ... only with collusion could someone use the cred who wasn't the subject 19:00:54 ... proposal VCDM should define a few simple binding types and support an extension mechanism for new types to be added 19:01:32 q+ to say extension methods are fine, but we need at least one normative way to do it. 19:02:40 ... This might work for biometrics too 19:03:55 will take the queue after the presentation 19:05:17 q? 19:05:30 q 19:06:44 PBastian: working on Eidas, interesting in holder binding. Started in DIF wallet security. 19:07:24 oliver: application of this are any where you need specific assurance or confidence to prevent identity fraud 19:07:28 q+ SamSmith 19:07:38 Paul_Bastian has joined #vcwg 19:08:04 gkellogg has joined #vcwg 19:09:06 ... Other systems use similar approaches. ISO mDoc, AnonCreds etc 19:09:23 ... There are some privacy considerations, these are similar to those in the VCDM 19:09:42 If there is interest, I can give an small analysis on eIDAS 2.0 on thursday, is it references W3C VC 1.1 directly, so this view might be intresting for 2.0 19:10:01 ... should be increased focus on selective disclosure for the property, as might include PII 19:10:17 ... verifiers can use other claims in credential aswell 19:10:41 q+ 19:11:02 ... there is a second part to this 19:11:19 ack dlongley 19:11:19 dlongley, you wanted to say we should refine the problem statement to rule out the collusion case 19:11:21 kristina: concretely this proposal about putting "binding" property into VCDM 19:11:58 dlongley: originally got in queue to suggest refine problem statement. To rule out collusion 19:12:12 ... should be explicit whether or not we are trying to cover this case 19:12:21 q+ to mention that DID Auth is something people already do, perhaps we need implementnation guidance on ways to do "identity assurance levels and NIST" 19:12:28 ... maybe we are trying to cover these collusion use cases 19:12:34 ... be explicit what we are protecting against 19:12:44 ... maybe not about binding, but rather what is probable 19:12:52 ack SamSmith 19:12:54 ... provable 19:12:57 s/what is probable/what is provable 19:12:58 s/what is probable/what is provable/ 19:13:07 markus_sabadello has joined #vcwg 19:13:31 SamSmith: agree we should have strong binding methods. There is many legit usecases when presenter is not the subject 19:13:42 q+ to say holder can be an additional subject 19:13:43 ... presenter designation should be metadata to the claims 19:14:01 q+ to say presenter is not under control of issuer. Lots of use cases where that use should be supported 19:14:02 that feels like combination of terms of use and other areas covered 19:14:56 ... Need to have an issuedTo as additional metadata 19:15:48 ... we can simplify complexities by moving designated presenter to metadata. Show link by having id of subject to this presenter in metadata 19:15:51 ack dmitriz 19:15:52 q+ 19:16:18 dmitriz: Understand the usecase. Holder binding firmly belongs in termsOfUse property. Issuer dictating how cred should be used 19:16:27 See https://w3c.github.io/vc-data-model/#terms-of-use 19:16:42 ... want to comment on publicKeyMethod. that is just redefining the DID spec. We already have a way to do this. 19:16:43 q+ 19:16:50 there is this cool did:jwk thing too ;) 19:17:01 ... if you are saying we don't have a way to use dids with vcs we should fix that 19:17:28 ... The idea to restrict VCs to certain wallets is horrifying. Users should be able to transfer creds between wallets. Key part of VCs 19:17:38 ... whole trust model has to do with keys and not the wallet 19:17:41 some use-cases require HW bound keys 19:17:46 manu_: these are valid usecases 19:17:54 so no moving between the wallets 19:17:58 +1 hw keys 19:17:58 ... Discussion is around where this goes in data model 19:18:14 q+ to say what about the proof section? 19:18:14 progress that we agree that we want this mechanism in vcdm 19:18:19 ... We have a mechanism to do key authentication - DID auth. Still need to connect some docs 19:18:30 ... This probably shouldn't go in the credSubject 19:18:33 ack manu 19:18:33 manu_, you wanted to note verification methods are a part of Data Integrity and are a part of "controller documents"... and to mention that DID Auth is something people already do, 19:18:36 ... perhaps we need implementnation guidance on ways to do "identity assurance levels and NIST" 19:18:40 "hw keys" doesn't necessarily mean "bound to wallet or device" either ... could just refer to key material being in hardware, but that doesn't preclude it being used from multiple places / locations / etc. 19:18:42 ... So where does it go - possible termsOfUse 19:18:49 not all use-cases use didauth 19:18:58 +1 kristina 19:19:21 most don't 19:19:26 @kristina - for use cases that don't use didauth, they don't need a separate re-defined 'publicKey' proof method. since that's just did auth 19:19:38 ... not everything uses did auth, but that does exist 19:19:54 ... this is about using alternate binding schemes other that DID auth. That is legitimate. 19:20:11 ack manu_ 19:20:12 ... need to do something about it, but need to consolidate with preexisting work 19:20:14 ack brentz 19:20:14 brentz, you wanted to say extension methods are fine, but we need at least one normative way to do it. and to say holder can be an additional subject and to say what about the 19:20:17 ... proof section? 19:20:29 binding isn't about restricting behavior, it's about linking two (or more) things together -- and we should be careful about that. 19:20:38 brentz: In general, if proposing a new extension method we need at least one normative way to do this 19:20:58 didauth is fine, i am just against limiting only to didauth, or make it look like didauth is the best/only way to do things 19:21:06 ... Need to define at least one way to use this property 19:21:18 agreed, I don't think anyone is saying "DID Auth is the only way to authenticate" 19:21:35 ... credentialSubject property can have as many subjects as you want 19:22:02 ... This is a way of securing a VC, from a specific viewpoint 19:22:16 @manu_ - I meann.. I'm sort of saying that why are we introducing developer confusion by having two ways of using key-based auth? 19:22:22 ... We could move holder binding proofs in proofSection. This could be a separate spec 19:22:22 q? 19:22:28 ack DavidC 19:22:35 DavidC: I have four points 19:22:42 +1 to holder binding being in the proof not inside the body of the VC 19:22:53 ... oliver said evidence should be out of scope. I disagree, some info should go in this property 19:23:04 ... I think paper confused identifier with identity 19:23:17 WG seems to disagree on 1/how to call this; 2/where to put the information 19:23:45 ... One interesting way this could be used is if vc method is an x509 distinguised name 19:23:46 perhaps if we could focus in on a non-controversial use case? 19:23:59 ... Seems these were all use cases of the nonTransferable property 19:24:15 i still feel like we have too many things we're trying to solve for at once, making it hard to figure out what to put where... +1 for focus on a use case 19:24:22 termsofuse, nontransferrable, credentialsubject, evidence 19:24:26 ... Therefore its a terms of use feature 19:24:35 q+ to focus on a non-controversial use case 19:24:41 ack JoeAndrieu 19:24:41 JoeAndrieu, you wanted to say presenter is not under control of issuer. Lots of use cases where that use should be supported 19:24:51 no the usecases in the paper include transferable VCs 19:25:05 q+ to note that DIDAuth, WalletBinding are controversial. 19:25:14 big +1 Joe - seriously hard work here 19:25:17 JoeAndrieu: I like this approach. The paper does a great job trying to understand the problem before solving it 19:25:23 q+ 19:25:26 Putting the holder as yet another subject in order to separate the holder/presenter from other subjects is an example of layer violation. Holder binding is a type of entitlement and is about control not about claims 19:25:32 ... I don't like termsOfUse or nonTransferable. These imply control structures 19:25:53 ... to me, a VC is an uttered statement. I care about who uttered it and if they still stand by it 19:25:54 gkellogg has joined #vcwg 19:25:55 would love to agree how the property will look like, before we debate where to put 19:26:13 ... We do have DIDs and auth mechanisms for DIDs, but we don;t have this for any other uris 19:26:22 +1 to JoeAndrieu for its a control structure -1 that we don't need control structures. 19:26:23 ... I like shift from binding to confirmation btw 19:26:32 kristina: where to put it is partially related to how it might look ... any property is an attribute of the entity in which it appears 19:26:52 ... How do we specify how you authenticate for a credSubject that identify an entity using a twitter url for example 19:26:58 wg also agrees the mechanism is optional 19:27:20 gkellogg has joined #vcwg 19:27:48 kristina: to summarise, lets focus on where we want to put this property and what it will look like 19:28:12 ... we have a bunch of options, lets move things forward 19:28:16 q? 19:28:19 ack oliver 19:28:41 oliver: dmitriz in my opinion this property is a claim made by the issuer about the credentialSubject 19:28:47 ... This is a valid claim 19:28:52 -1 oliver. it's a credential claim. 19:29:02 gkellogg has joined #vcwg 19:29:04 ... We are not saying this can go in a single wallet 19:29:11 @dlongley "property" might have been a wrong name - more like structure, but at the high level, sure :) 19:29:16 :) 19:29:19 s/name/word 19:29:29 ... We are not trying to redefine DIDs, it was just an example 19:29:30 saying some entity has some identifier (an identifier with this special cryptonym-like property) makes sense in the `credentialSubject` to me ... saying more about ways to authenticate / get identity assurance and so on could easily belong somewhere else. 19:29:54 it's a claim about how a subject relates to a credential, so it could validly fit in either place 19:30:23 ... manu_ if you want to use VCs online, verifiers are interested in if this VC is being presented by the entity it was issued to 19:30:40 confirmation method seems to be dominant one that people agree with.. 19:30:40 ... Better to define a single place for this information 19:30:54 ... Really challenging to implement this use case today 19:31:09 ... to SamSmith yes this is a simplification. It is a good one. Makes it simpe to implement 19:31:13 q+ 19:31:52 ... I also fully acknowledge there might be other roles that need to be defined. 19:32:18 VCs in general contain two types of claims. 1) claims about the VC (like issuer, validUntil, etc). and 2) claims about the subject. Binding is about the vc 19:32:21 brentz: this proposal does support multiple credentialSubjects. This is one reason this should go in cred subject 19:32:29 q+ what if we show an example w/o DIDAuth, w/o wallet binding, w/o a DID? 19:32:30 ... don't like to proof section approach 19:32:35 validUntil is also a claim. but it doesn't belong in subject 19:32:37 q+ to note what if we show an example w/o DIDAuth, w/o wallet binding, w/o a DID? 19:32:58 oliver: This should not go in the evidence property. It is not the core we are trying to solve here 19:33:05 the plan is to have a break at 3pm, spend 4-5pm on extensibility points, and defer terminology issues to thu and have snacks at 5pm (used to be lunch) - times in EST 19:33:08 q+ isn't this an identity proofing event and wondering if you want to re-use the same event? 19:33:13 I think having to look inside the payload to verify a proof of entitlement to present a payload is more complicated for the verifier especially if the payload contains claims for other subjects. 19:33:26 ... conf binding could support x509 identifiers 19:33:29 I can imagine a scenario with evidence, proof, termsOfUse and 6 subjects, 5 bound to keys and 1 bound to a human subject id... 19:33:31 q+ to note isn't this an identity proofing event and wondering if you want to re-use the same event? 19:33:49 ... JoeAndrieu thanks for positive suggestions. I also prefer confirmationMethods 19:33:54 dmitriz: agreed wrt. claims about VC vs. claims about the credential subject... and thinking about how claims are really assertions that entity X has attributes Y (and there can be many different entities) 19:34:03 kristina: you still argue the best place to put this is the credSubject 19:34:08 oliver: yes 19:34:13 ack Paul_Bastian 19:34:40 Paul_Bastian: First point is if the intention of VC spec to have a strong link to DID core spec. 19:35:01 ... Seems weird to me. eidas uses the VCDM but never references DIDs 19:35:09 ... Dont need DIDs for keyConfirmation binding 19:35:42 a DID is a type of identifier that has a cryptographic binding, that doesn't mean DIDs must be used for that, but that's a thing they are for. 19:35:46 q? 19:35:52 ... We simplified problem. This just shows how someone can confirm that they are the subject of a credential 19:35:54 A credential could have multiple subjects each with a different confirmation method. Some might view this as beneficial flexibility but it then puts a burden on the verifier, it makes it more complex. Its not necessarily a simplification. 19:36:25 ... Paper also proposes other places this property coould live. I prefer it to be under credSubject too 19:36:37 ... I don't care too much about it 19:36:37 q+ to talk about VC claims vs subject claims 19:37:29 q+ 19:37:29 ... All credentials should be exportable, not the intention of this work. Check out the eidas ARM 19:37:32 https://datatracker.ietf.org/doc/html/rfc7800 19:37:46 "binding" is just another word for "linking" ... we could think of every asserted attribute as a binding/linkage to some value -- the special property of "binding" is that there's a cryptographic operation that can only be performed by the controller of a secret (or one of their delegates) 19:37:58 ... To achieve regulated use cases you need to use hardware keys, these will be non exportable. That is unavoidable 19:38:15 cnf claim that can be used instead of dids is defined in rfc 7800 https://www.rfc-editor.org/info/rfc7800 19:38:17 RFC7800 defines the cnf claim 19:38:36 ... This is not just another claim, because we want the syntax to be very clear about how to confirm the subject 19:38:39 also EUDIW ARF https://digital-strategy.ec.europa.eu/en/library/european-digital-identity-wallet-architecture-and-reference-framework 19:38:51 q+ 19:38:53 In plain JWT world, if we do something other than cnf for this... we should expect some pain. 19:39:12 ... in my opinion only the issuer knows how to confirm who the subject is. They should give guidance to the verifier for how to do this 19:39:16 also type2 in EUDIW ARF is only to illustrate the concept of "configurations"/"profiles" - EAA mandates type1 19:39:25 q? 19:39:33 ack manu_ 19:39:33 manu_, you wanted to focus on a non-controversial use case and to note that DIDAuth, WalletBinding are controversial. and to note what if we show an example w/o DIDAuth, w/o wallet 19:39:36 ... binding, w/o a DID? and to note isn't this an identity proofing event and wondering if you want to re-use the same event? 19:39:47 manu_: Feel like we are jumping all over the place. Can we pick and focus on one use case 19:39:59 ... Desire to solve this, but lack focus 19:40:15 @will but we can have more than one subject so saying "the subject" is making an assumption that if true means we can't support the use case I presented where the subject is not the designated presenter/holder its assuming away the ambiguity of multiple subjects each with its own confirmation method. 19:40:18 ... Lets take DID Auth and hard wallet binding off the table 19:40:41 ... E.g. okay I have a VC, it doesn;t have a DID in it. The uni used a passport to verify the subject 19:41:15 gkellogg has joined #vcwg 19:41:23 oliver: pseudonymous claims is a useful one. E.g. I passed some course online, but I don't want to provide any additional PII to this VC 19:41:35 q? 19:41:39 Paul_Bastian: this example is in the paper 19:41:45 Sorry @will I am confusing the scribe with the speaker 19:41:55 q+ 19:42:03 any use case where a person shares very little about themselves to get an entitlement may easily allow fraud via collusion 19:42:05 manu_: Can we isolate this to one example 19:42:24 I agree, the discussion on hardware-binding is separate 19:42:29 q+ to suggest marriage license use case 19:42:33 q+ 19:42:53 kristina: don't we want a mechanism that works for all use cases 19:43:00 manu_: we do but lets focus on one to start with 19:43:32 andres has joined #vcwg 19:43:57 kristina: any use case to start with 19:44:05 ivan_ has joined #vcwg 19:44:22 q? 19:44:36 ack Orie 19:45:01 Orie: need to understand other specifications that address this concern 19:45:07 ... Why are they not enough. 19:45:17 ... should look at rfc7800 19:45:25 q+ to bring up NIST AAL, IAL, etc. 19:45:39 ... confimation claim isnt a subject it is a separate claim 19:45:58 please don't limit holder binding to keys! its better understanble if you think how to address both remote & on-site usecases with the same VC 19:46:20 ... terms of use is interesting. Is this something you dig in to do validation 19:46:28 ... is evidence a place I am going 19:46:35 @Paul_Bastian - I don't think anyone is proposing to limit binding to just keys. There's a reason why we called the property 'proof' and not 'signature', cause it's for more than just keys 19:46:38 one example with cnf claim to help people imagine how it can look like: https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-02.html#section-5.3 19:46:39 q+ 19:46:39 ... We should all read rfc7800 19:46:49 yes, what Paul just said, can we focus on that bit? Where are the things where you don't use cryptographic keys? Identity Assurance events? 19:47:04 ... Why are we reinventing that 19:47:48 ... cnf is a direct drop in for the binding property 19:47:52 ack Paul_Dietrich_DS 19:47:53 +1 orie 19:47:53 https://www.rfc-editor.org/rfc/rfc7800.html 19:48:03 and mixing that with claims 19:48:13 Paul_Dietrich_GS1: On slide 29, mentioned about trusting the issuer. This is contextual to the claims 19:48:21 KDeanGS1 has joined #vcwg 19:48:22 przemek has joined #vcwg 19:48:26 q+ 19:48:41 i strongly disagree with cannot trust the issuer 19:48:54 +1 kristina, that's outside of the VC trust model 19:48:55 ... This is a claim about the subject, these can be ignored. 19:49:04 ... Where does it sit. This is optional for issuer and verifier 19:49:13 q? 19:49:15 ... I do see how this is needed 19:49:16 kristina: i think the idea is that you may trust an issuer for claims X, Y, and Z ... but not for A, B, or C. 19:49:23 ack Paul_Dietrich_GS 19:49:25 ack dmitriz 19:49:25 dmitriz, you wanted to talk about VC claims vs subject claims 19:49:29 if you don't trust them for anything in their credentials, then yeah, that's out of scope 19:49:56 dmitriz: responding to oliver comments that developers will be confused if they have to look in multiple places for claims 19:50:04 ... that ship has sailed in the VCDM already 19:50:28 dlongley: yes, and i disagree verifier cannot trust the issuer for confirmation methods :) 19:50:39 ... developers always have to look in places other than the credentialSubject 19:50:47 ack SamSmith 19:50:50 q+ to ask if this could just be handled with a vocab? 19:50:57 kristina: i think any confirmation methods would just be statements by the issuer that the issuer would trust those methods ... and it's up to the verifier to decide whether to use them or not 19:50:57 zakim, close the queue 19:50:57 ok, kristina, the speaker queue is closed 19:51:00 brent has joined #vcwg 19:51:03 q+ to talk on prior approaches 19:51:08 thats not true, a VC can hjave multiple subjects, how do you know which is meant? 19:51:15 q? 19:51:15 dlongley: whether to use or not is absolutely up to the verifier 19:51:23 +1 19:51:32 (to kristina) 19:51:35 SamSmith: If going to have subject based verification method. And have VCs with multiple subhects. Makes this extremely different for verifier to interpret 19:52:06 ... If instead only allow one subject to have a confirmationMethod, this makes it simpler 19:52:12 Agree regarding multiple subjects being... maybe not well thought through... we don't have enough normative constraints on that feature for it to be used safely IMO. 19:52:12 ack oliver 19:52:35 q? 19:52:51 heh +1 to what SamSmith is saying. I wouldn't mind restricting VCs to just a single subject (just as we restrict them to a single issuer, currently). would cut down on the complexity. if you want multiple subjects, issue several VCs. 19:52:54 oliver: SamSmith I agree it can be confusing if multiple credSubject each have confimationMethods 19:53:27 can i give my place to dwaite - i think his comment will be important precursor to concrete next steps 19:53:34 ... dmitriz sure, but always better to make it as easy as possible for verifiers 19:54:19 ... Paul_Dietrich_GS1 if an issuer is not able to create this confirmationMethod then they don;t do it. 19:54:34 ... if it is there then that is cause the issuer has enough certainty to make this statmeent 19:54:54 ... Orie I will look into rfc7800 19:55:40 ack kristina 19:56:19 kristina: Don't need to fit everything into this mechanism. 19:56:36 idea for a proposal - we add a confirmationMethod property that is extensible and point to rfc7800 as one normative way to do it 19:56:47 ... see the usability of this mechanism on non crypgraphic mechanisms. E.g. biometrics like facId 19:57:01 q? 19:57:07 ack JoeAndrieu 19:57:07 JoeAndrieu, you wanted to suggest marriage license use case 19:57:39 JoeAndrieu: agree with concern SamSmith raised. But solution is already there. 19:58:15 ... e.g. for a marrage certificate, there is multiple legitimate subjects of the VC. Each could be bound to a different subject 19:58:21 q? 19:58:28 gkellogg has joined #vcwg 19:58:29 zakim, close queue 19:58:29 ok, kristina, the speaker queue is closed 19:58:59 ... Limit the scope to one of the binding mechanisms. Focus on the scope of what we really mean 19:59:05 q 19:59:13 ... Does it need to be automatable, are we talking about cryptographic 19:59:14 ack DavidC 19:59:23 DavidC: concerned that we might end up with duplicate 19:59:50 ... If we decide we want binding on PII e.g. name then we put it in the confirmation then these terms would be duplicated 20:00:00 ... don;t need confirmation method when it is obvious 20:00:14 ... need it when not obvious, e.g. x509 certificate 20:00:22 ack manu_ 20:00:22 manu_, you wanted to bring up NIST AAL, IAL, etc. 20:00:27 ... Might just be duplicating properties in credSubject 20:00:34 manu_: We are talking about events 20:00:49 ... issuer did x to verify the credentialSubject on issuance 20:01:35 q+ 20:01:37 manu_: I am confused 20:02:03 oliver: We are not talking about the issuer did x to verify cred subject. 20:02:22 q? 20:02:29 ... issuer says you can use this mechanism to authenticate the subject of the credential 20:02:54 ... The confirmationMethod is a tool for the presentation process 20:03:02 ... provides inf to the verifier 20:03:29 q+ to say it's not about what the issuer did 20:03:41 manu_: understood, but if the issuer hasn't checked the things they put in the confirmationMethod then they shouldnt be putting this information in here 20:03:45 q+ 20:03:49 q 20:03:49 q? 20:03:52 q? 20:04:02 ack BC 20:04:15 BC: lost some context, but want to add some clarity to Orie points 20:04:41 ... rfc7800 provides ways to represent a key with the intent that during presentation of that token proof of possession of that key is included 20:04:48 ... intentionally limited to single key 20:05:06 ... about the key with respect to presenting a token. Not necessarily about subject 20:05:31 ivan has joined #vcwg 20:05:42 q+ 20:06:11 ack Paul_Bastian 20:06:23 decentralgabe has joined #vcwg 20:06:33 Paul_Bastian: talking too much about different binding mechanisms. 20:07:05 ... one of main idea of paper was to support different uses of VC. Remote, hybrid or offline and inpeprson 20:07:18 ... idea is we have a VC that can be used remote, online, automated or not. 20:07:27 ... diff confirmation methods work for different scenarios 20:08:00 ... we have array of confirmation methods to support these different sccenarios 20:08:13 ... This is about providing a registry to name these types of confirmation 20:08:53 ack mprorock 20:08:53 mprorock, you wanted to ask if this could just be handled with a vocab? 20:09:33 mprorock: regulatory environment will require this kind of thing 20:09:44 ... is there a way we can avoid registries of things 20:10:01 ... also does this exist elsewhere. If so lets point to those things 20:11:53 kristina: lets take a break, are we ready for a concrete proposal 20:12:18 @brent - what if, instead, we propose to limit VCs to just one credentialSubject :) (could simplify the conversation greatly!) 20:14:19 gkellogg has joined #vcwg 20:14:52 how long is this break? 20:29:21 gkellogg has joined #vcwg 20:33:03 BC - we are scheduled to resume three minutes ago. :-) 20:36:40 mprorock has joined #vcwg 20:36:57 manu_ has joined #vcwg 20:37:03 selfissued has joined #vcwg 20:37:12 Phil_F has joined #vcwg 20:37:20 present+ 20:37:20 decentralgabe has joined #vcwg 20:37:29 oliver has joined #vcwg 20:37:30 q+ 20:37:35 q+ to talk about subject binding 20:37:38 present+ oliver 20:37:38 q+ 20:37:41 zakim, open the queue 20:37:41 ok, brent, the speaker queue is open 20:37:41 dwaite has joined #vcwg 20:37:43 Orie has joined #vcwg 20:37:43 q+ 20:37:44 q+ to talk about subject binding 20:37:45 q+ 20:37:47 q+ 20:37:47 Will has joined #vcwg 20:37:47 samsmith has joined #vcwg 20:37:47 q+ 20:37:51 q+ 20:37:58 q+ to define a marriage license use case with one spouse using DID and DID Auth, the other using a passport and offline confirmation 20:38:58 scribe+ 20:39:02 @JoeAndrieu - ha, I was gonna mention marriage license use case too. :) (in the argument that we can restrict VCs to a single credentialSubject) 20:39:28 Topic: Concrete Proposals for Holder binding 20:40:27 ack oliver 20:40:32 Brent: be brief, if someone else says your idea, please remove yourself from q 20:40:32 q/ 20:40:39 q? 20:40:42 q: 20:40:43 q 20:41:02 gkellogg has joined #vcwg 20:41:39 oliver: proposal is to focus on bikeshedding name, property location, property contents? 20:42:05 ... lets discuss this slide 20:42:20 ... should we use an extension registry for types for holder binding? 20:42:44 ack decentralgabe 20:42:44 decentralgabe, you wanted to talk about subject binding 20:42:56 decentralgabe: +1 to registry and extension mechanism 20:43:07 ... we should handle this like evidence / type 20:43:17 ... we should add MUST requirement for the issuer 20:43:30 ... subject evidence property proposal. 20:43:33 q+ 20:43:34 scribe+ 20:43:36 ack Orie 20:44:15 gkellogg has joined #vcwg 20:44:18 orie: believes we should separate the core data model aspects from mechansims and processing rules which should be handled in the securing specs 20:44:24 scribe- 20:44:25 ack DavidC 20:44:46 davidC: proposal we don't need to cover claims in the subject use case. 20:45:01 ... issuer should not use confirmation for subject claims. 20:45:17 ... the use case we should cover, is when its hard to link the credential to the user. 20:45:22 gkellogg has joined #vcwg 20:45:32 ... when its not obvious how to link confirmation to the user 20:45:34 ack dmitriz 20:46:08 dmitriz: proposal 1: move confirmation method to terms of use, where it should contain an array of confirmation method types. 20:46:31 ... proposal 2: we should restrict the core data model to only having 1 subject, just as we currently have only 1 issuer. 20:46:50 ack samsmith 20:46:59 ... we can cover all use cases without having multiple subjects, and multiple subjects does not play well with evidence and binding. 20:47:01 q+ 20:47:18 samsmith: We should look at the use cases and threat analysis 20:47:40 ... we should not hand have around security guarantees regarding subject claims 20:47:44 ack JoeAndrieu 20:47:44 JoeAndrieu, you wanted to define a marriage license use case with one spouse using DID and DID Auth, the other using a passport and offline confirmation 20:47:48 ... we should do a threat analysis 20:48:12 same 20:48:20 JoeAndrieu: proposal is we should do marrage license use case, and do 2 scenarios, did auth and passport confirmation methods 20:48:25 same 20:48:29 ... I don't think we need registries 20:48:34 audio cut out 20:48:45 and it's back 20:48:54 ... security is not about validation... this is business rules, not crypto. 20:49:09 brentz has joined #vcwg 20:49:11 q? 20:49:19 ... I agree with davidC, we should avoid duplicating if we can, but we may need to refer to things... do support confirmation methods 20:49:45 ... curious regarding dimitry's single credential subject for marriage certificate. 20:49:56 officers of a company is another example 20:50:17 ... we are in , and we picked this path... based on discussions 20:50:26 ack oliver 20:50:29 q+ 20:50:32 oliver: I like the term "confirmationMethod" over "binding" 20:50:38 i think there may be some confusion between (multiple) "top-level" credential subject and nested subjects... either way, there will always be the possibility and need for nested subjects 20:51:03 +1 dlongley, re nested entities 20:51:07 ... to orie's point on layering... in general +1, but I want to define a framework... where each confirmation method has a type. 20:51:13 +1 to confirmationMethod 20:51:14 ... where each type defines what gets confirmed 20:51:18 ... what the issuer intended 20:51:27 ... we should define 1 or 2 types 20:51:28 it's not clear what is being confirmed ... what is being confirmed? 20:51:43 ... or we will encounter formal objections, similar to termsOfUse and Evidence. 20:51:55 ... we should look at holder used MFA use case. 20:52:03 ... maybe look at FIDO use case 20:52:16 ... i think confirmation is a claim on the credential Subject 20:52:23 ... I don't think it belongs in termsOfUse 20:52:41 what does it mean if the confirmation method is the jpeg photo of the user? That the issuer checked this photo? What does it mean if the jpeg photo is not listed as a confirmation method? That the issuer did not check the photo? 20:52:41 ... regarding samsmith, I think the use case document covers some threat analysis 20:52:47 +1 20:52:56 are you always confirming some level of identity assurance? ... should these be identity assurance methods? 20:53:25 oliver: joes said he did not like regististries, but he does like types 20:53:34 ack dwaite 20:53:39 q+ 20:53:54 gkellogg has joined #vcwg 20:54:21 dwaite: the issuer is also saying, if you don't process the information, you are doing this at your own peril... in extension points, we need to make sure that people understand mandatory processing rules and consequences for ignoring them 20:54:50 ... if a verifier ignors the issuer's intent, the issuer is not liable for verifiers ignoring claims 20:55:03 ack brentz 20:55:11 ... its not clear if termsOfUse or claims is correct... there are no processing rules a verifier must follow 20:55:18 q+ to question "confirmation method" ... i think what's being confirmed is that the thing the issuer meant to identify by identifier X ... is the same thing that the verifier thinks it is 20:55:31 brentz: seems like confirmationMethod seems to generally by well received term? 20:55:37 gkellogg has joined #vcwg 20:55:48 @oliver - I'm super curious why you feel that confirmation method is a claim about the subject. Issuers make several claims, in the VC. 'evidence' contains claims that the issuer checked the following documents to ascertain identity. 'termsOfUse' contains claims that the issuer requires that when verifiers accept the credential, they should use these methods to confirm identity. Neither of those are about the subject. 20:55:53 general agreement its better than binding in the room... 20:56:03 brentz: what do we want this thing to do? 20:56:09 q+ 20:56:14 ... what is the one thing that we want to do 20:56:30 ack Paul_Dietrich_GS1 20:56:32 tell the verifier how to validate a subject.id that it is not obvious how to do this 20:56:38 q+ 20:56:42 q+ to agree on one thing it should do -- identity assurance <-- from sam 20:56:43 AssuranceMethod 20:56:51 +1 to assurance method ^^^ 20:56:51 gkellogg_ has joined #vcwg 20:56:55 +1 for assuranceMethod 20:56:58 q+ 20:57:06 assurance is better ... but i think would be better with a modifier to go with "assurance" 20:57:09 Paul_Dietrich_GS: +1 on confirmationMethod, name seems good.... the data structure, seems like it needs to relate to evidence, termsOfUse and credentialSubject claims 20:57:16 ... maybe its a seperate document 20:57:20 @dlongley - like 'identityAssurance' ? 20:57:23 +1 to different doc 20:57:24 +1 to "modifier to go with assurance" 20:57:26 ack Paul_Dietrich_GS1 20:57:31 ack Paul_Dietrich_GS 20:57:33 authenticator assurance is also a thing :) per NIST 20:57:37 -1 different doc 20:57:40 ack dlongley 20:57:40 dlongley, you wanted to question "confirmation method" ... i think what's being confirmed is that the thing the issuer meant to identify by identifier X ... is the same thing that 20:57:43 ... the verifier thinks it is 20:57:51 q+ to say assuranceMethod maps well to actually providing multiple levels, so verifiers can use the level they need 20:57:57 dlongley: I question confirmationMethod, because its only working in a narrow context 20:58:01 gkellogg has joined #vcwg 20:58:09 q+ 20:58:23 ... do you really need a confirmation method for: do you have a cat? 20:58:29 +1 20:58:32 +1 dlongley 20:58:34 ... are these really just "identity assurance" 20:58:35 ack mprorock 20:58:39 q- 20:58:45 general agreement assurance seems good. 20:58:53 +1 20:58:56 -1 20:58:56 mprorock: identity assurance seems good 20:58:58 +q 20:59:03 q+ 20:59:07 ... is this just a list of things an issuer checked 20:59:09 q+ 20:59:14 ack Will 20:59:39 Will: DavidC mentioned that this is useful for when the subject identifier is not clear, I don't love confirmation method 20:59:50 ack manu_ 20:59:50 manu_, you wanted to agree on one thing it should do -- identity assurance <-- from sam 20:59:55 -1000 identity assurance 21:00:03 manu_: I agree with Sam and Dave, we are talking about assurance 21:00:21 ... this seems related to identity assurace, authenticator assurance... that feels concrete 21:00:21 Subject identity assurance? 21:00:48 +1 to it being what the issuer checked ... and the verifier could check it too if they want to. 21:00:53 q+ to say sometin 21:00:55 we already have a place for 'the issuer checked this', which is the 'evidence' field 21:01:04 ... we are talking about assurance, but what are we really saying, did the issuer check, or is the issuer asking the verifier to check 21:01:09 ack DavidC 21:01:23 davidC: there is a CCG draft for evidence property use case and KYC 21:01:28 q+ to say that it is what the verifier should check 21:01:39 ... OIDF is looking at how to use evidence for this use case 21:01:48 q+ to say this is about the verifier getting assurance that the thing they think X means is the same thing that the issuer thought X was ... so the issuer should say what checks they did so the verifier can do them too if they want to 21:02:05 ... lots of work happening in OIDF on evidence, we should use what OIDF is doing for assurance 21:02:24 ... I think this is not about assurance, its about the identifier, not the identity attributes 21:02:37 ... this identfier should be checked on presentations... 21:02:41 ack JoeAndrieu 21:02:41 JoeAndrieu, you wanted to say assuranceMethod maps well to actually providing multiple levels, so verifiers can use the level they need 21:03:07 JoeAndrieu: We need to distinguish, how should a verifier process a presentation 21:03:13 +1 to Joe 21:03:13 ... I would not call that identity assurance 21:03:19 subjectAuthMethods 21:03:22 ... I would say it is assurance though 21:03:31 ... we are not trying to track a physical body 21:03:38 ... we are trying to correlate activities 21:03:48 ... we are not confirming DNA / presence, etc... 21:03:48 q- 21:03:58 ... I do think it needs to be open ended 21:04:10 ... people don't have identifiers 21:04:41 time boxing intensifies 21:05:15 ack oliver 21:05:19 oliver: I agree 21:05:30 ... mumbles about sleep... 21:05:44 i resemble that remark 21:05:58 ... this is about the process of ... assurance, but not identity assurance 21:06:17 q+ to add about assurance level choices 21:06:25 ... NIST has stuff on this, IAL, AAL, FAL... but that seems not what the verifier does, its what the issuer does 21:06:26 gkellogg has joined #vcwg 21:06:48 ... when I speak of assurance, I think about the full lifecycle 21:07:13 ... proof of possession for holders, MFA, etc... Identity Assurance boxes us in... i don't like that 21:07:28 ... EIDAS does not distinguish between all of these, but they do have levels 21:07:34 and by 'holders' we mean 'presenters', right? 21:07:42 ... they have lots of stuff that we don't want put in the credential 21:07:48 ack oliver 21:07:55 ... I like abstraction that saves us from embedding all that 21:08:06 ack samsmith 21:08:24 samsmith: do we need to do both? id assurance by issuer vs id assurance by the verifier? 21:08:33 ... we should cover both cases in this method 21:08:41 ... there are liability concerns that vary 21:08:46 evidence is for what did the issuer do 21:08:51 q+ to suggest "this is what the issuer did to get to a certain level of assurance... you could choose to do the same things too, if you'd like." 21:08:56 +1 to cover both issuer evidence & verifier guidance with similar means 21:09:02 ... verifiers need to know what issuer intended, and how to comply to benefit from liability coverage 21:09:15 ... internals might not need to be communicated to verifier 21:09:18 q- 21:09:19 q+ to ask if the verifier must check this stuff - and to clarify that this is in relation to the subject - e.g. methods by which the subject may prove that they are who they say they are? 21:09:19 +1 to Oliver that identity assurance is not an appropriate term 21:09:20 scribe+ 21:09:23 ack Orie 21:09:56 orie: evidence is the part of the spec that we have today that covers the process that the issuer has undergone prior to issuance to subject. When we speak about IAL about issuer makes about a subject, evidence is the thing that covers that.. 21:10:05 drummond_ has joined #vcwg 21:10:08 Orie: On the issuer appraisal side of this, evidence is wha we should use/remove. 21:10:19 I agree with Oliver that the property should NOT be called "identity assurance" because that's not what NIST means by that term. 21:10:27 it doesn't help that evidence isn't really defined - is evidence identity related or claims related or and either/or situtation 21:10:31 IMHO the best term is "vc-to-subject-binding". 21:11:01 orie: Agree that what we talk about here when what issuer intends verifier to do... issuer communicating intent for receiving benefit, or if they don't apply, they are operating under their own risk... bouncer might let you into bar with an expired driver's license, you take that risk. 21:11:19 q+ to say we may need something other than evidence 21:11:35 orie: verifier process is separate from evidence process, let's keep them separate, regarding where we keep specific claims... don't know if it's terms of use, or part of credential subject, if we don't say that, it'll end up in both places, mixed. 21:11:37 ack JoeAndrieu 21:11:37 JoeAndrieu, you wanted to add about assurance level choices 21:11:45 could split the difference by using "identityConfirmationMethod" ... but i think this just points out that "confirmation" is really just assurance, you can't fully "confirm" it 21:11:56 JoeAndrieu: Should we use the same mechanism for Evidence for this? 21:12:21 assuranceMethods vs identityAssurance 21:12:22 q- 21:12:26 ... evidence they used to establish global entry is different than what verifier might use to process claims 21:12:39 ... different jursidications might have different requiremetns 21:12:56 ... the verifier might not be able to use all confirmation methods proposed by the issuer 21:12:59 +1 joe 21:13:01 ack manu_ 21:13:01 manu_, you wanted to suggest "this is what the issuer did to get to a certain level of assurance... you could choose to do the same things too, if you'd like." 21:13:13 manu_: Feels like evidence is easy to use 21:13:13 q+ 21:13:14 +1 to what Joe is saying. I'm struggling to see how an issuer could picture all the possible ways a verifier would want to verify a VC. 21:13:30 q+ to say what the issuer checked about whom? 21:13:35 ... I am concerned about adding constraints for the verifier, and presumption of liability transfer 21:13:46 ... that seems to raise the specter of lawyers 21:14:08 ... concerned about the second part of this, and communicating the requirements to verifiers 21:14:15 ... seems like issuers might get that wrong 21:14:18 q+ 21:14:28 +1 to avoid "liability" in our languaging 21:14:29 ... seems there is danger, expressing "non liability" 21:14:40 q+ 21:14:45 ... can we tackle the evidence use case first? 21:14:45 ack mprorock 21:14:45 mprorock, you wanted to ask if the verifier must check this stuff - and to clarify that this is in relation to the subject - e.g. methods by which the subject may prove that they 21:14:48 ... are who they say they are? 21:15:05 mprorock: clarifying this is related to the credential subject 21:15:17 ... but I keep hearing this is about what a verifier MAY do 21:15:33 ... what methods might a verifier use to verifify the subject is authentic? 21:15:41 ... maybe its not ID assurance... 21:16:05 ecosysystem governance frameworks around a given ecosystem set of VCs can clarify the "lawyer" issue significantly This can then express the may, should, must business logic and liability of the verifiers identity assurance method 21:16:07 ... we should cover the notion of levels / priorities for confirmation methods 21:16:20 ... seems like we are hearing requirments regarding levels 21:16:34 ... are these real requirements, or are they in conflict? 21:16:40 btw, the credential subject doesn't have to be a person -- so perhaps we need to avoid saying "the subject is who they say they are" and instead say "the subject is the same subject the issuer claimed it was" 21:16:56 ... we should list confirmation methods and protocols needed 21:17:06 ack brentz 21:17:23 brentz: We should communicate the options to the verifier 21:17:33 ... maybe you want to use holder binding? 21:17:40 ... are we ready for a PR 21:17:41 must the issuer check this stuff before including it? 21:17:41 kristina has joined #vcwg 21:17:46 ack JoeAndrieu 21:17:46 JoeAndrieu, you wanted to say what the issuer checked about whom? 21:17:47 present+ 21:17:53 JoeAndrieu: I think we are ready for PR 21:17:59 ... go do a PR oliver 21:18:16 or perhaps the language should be "the presenter can prove control over the identifier used for a subject in the VC" 21:18:27 ... on the notion of evidence, we can't use the current top level property for this... because we use evidence for different things today. 21:18:35 ... we need evidence for claims? 21:18:41 +1 to evidence on a subject basis 21:18:47 ... it needs to be tied to claims, not to the vc 21:19:03 ... lets put stuff in the credential subjet 21:19:03 ack samsmith 21:19:19 samsmith: +1 to adding evidence at the subject level 21:19:37 ... ecosystem governance is where the legal issues will get solved 21:19:59 ... it will business, industry, regulatory... we don't need to add that to the VC itself 21:20:15 ... if we don't all people to use practical legal frameworks, we won't get to practical use cases 21:20:22 q? 21:20:27 ack oliver 21:20:28 ... and real world use case, won't work, because law is more complicated 21:20:29 q+ to say lets avoid "liability" 21:20:34 oliver: I agree 21:21:02 ... yes. 21:21:15 ... the current evidence property might need work 21:21:24 ... I will try to make a PR 21:21:34 ... in the VCDM 21:21:42 ... I will propose a framework 21:21:50 present+ 21:21:53 ... after there is small agreement, I will try for an example 21:21:56 q+ 21:22:00 ... we also need to update the use case document 21:22:03 ... I am happy 21:22:08 ... I know what I need to do 21:22:16 ack JoeAndrieu 21:22:16 JoeAndrieu, you wanted to say lets avoid "liability" 21:22:28 JoeAndrieu: I will split the difference on agreement with Manu 21:22:38 ... we need to be careful about stating re liability 21:22:56 ... we should be clear regarding liability 21:22:59 +1 JoeAndrieu - this is about methods 21:23:05 ack samsmith 21:23:39 gkellogg has joined #vcwg 21:23:40 samsmith: We should have a PR, that includes separating crypto assurance from data model payload / claims 21:23:47 Topic: Extension Points 21:23:56 q+ 21:24:02 q+ to speak to 'render' :P 21:24:24 brentz: look at these things that need to be fixed 21:24:47 ... we need to fix dereferencing 21:25:27 brentz: first question, where are these terms defined 21:25:36 ... second question, look at these extension points 21:25:37 q+ to say if you deference an `id` URL you get a thing representing what the `id` identifies, if you dereference `type` you get a description of the type, if you dereference `issuer` or `holder`, you get controller document with verification methods for those things 21:25:42 ... all these are non normative 21:25:54 ... and we don't even point to a single way to use them 21:25:54 URL?? Did this change in 2.0? In 1.1 I though they were URI? 21:25:59 q+ 21:26:06 ... we need to point to something 21:26:09 Paul_Dietrich_GS1: URL is the same thing as URI in the new world. 21:26:14 q+ to note that refreshService has an implementation. 21:26:34 ... the reason for this, is because... we have been dinged on our charter for this stuff 21:26:49 ... its considered to be not a good thing, what we have done. 21:26:58 ... we feel we can do better 21:27:21 ... what should we do about these things? 21:27:22 q+ for schemas 21:27:34 ... should we remove these things... since we have nothing to point to 21:27:38 q+ to ask if ToS is in both VC and VP 21:27:40 q+ 21:27:45 scribe+ 21:27:53 ack Orie 21:28:09 not that button... (audio out again) 21:28:15 for refresh: issues 981, 1020 21:28:27 for terms of use: issue 1010 21:28:43 audio is still out :( 21:28:54 orie: illuminates us with the wisdom of having 10k registries.... then ends snark and procedes to suggest that unless we can define one normative type for each item on this list that they should be dropped 21:29:07 issue 991 says it is about status, but not really.. 21:29:22 +1 orie! 21:29:34 ... removing them from the doc does not mean they aren't useful or fine, just that they don't belong in the spec 21:29:41 mkhraisha has joined #vcwg 21:29:59 ... let's avoid FOs, let's do a better job 21:30:07 ... let's get things polished, then add 21:30:08 ack manu_ 21:30:08 manu_, you wanted to speak to 'render' :P and to note that refreshService has an implementation. 21:30:10 scribe- 21:30:18 @Orie - do you think we can thread the needle by just having a list of 'reserved terms' in the main VC WG spec? 21:30:24 manu_: there is also a render extension 21:30:35 ... we have one for status 21:30:43 ... we could point to the CCG for some of these 21:30:52 ... for refresh for example 21:31:04 q+ 21:31:11 ... as far as dereferncing, it depends on the type 21:31:11 as in, would 'reserved terms' without definition raise objections? 21:31:20 ... in many cases, its just a URL 21:31:29 ... sometimes its a URL to another file type 21:31:40 ... not sure what we can do, to fix this 21:31:51 ... they can be ANY url 21:32:14 brentz: Can we say more than, it is just a URL 21:32:20 ... we need to define it a bit more 21:32:37 manu: what about a human readable web page? 21:32:54 brentz: we need at least 1 way to do things 21:33:00 ... we don't need more than 1 21:33:24 q+ to suggest removing those sections from the spec, and adding a 'reserved terms' section, for future specs. 21:33:35 ... people need to be able to read the spec to understand how to use these extension points 21:33:37 ack dlongley 21:33:37 dlongley, you wanted to say if you deference an `id` URL you get a thing representing what the `id` identifies, if you dereference `type` you get a description of the type, if you 21:33:40 ... dereference `issuer` or `holder`, you get controller document with verification methods for those things 21:34:03 dlongley: we should also say, these id's depending on where they occur, they don't need to derefernence to things 21:34:13 ... we should explain when urn:uuid is more appropriate 21:34:17 +1 uuid - that is often a desired behavior 21:34:33 ack mprorock 21:34:41 ... we should describe what a holder dererefernces too, it should go to a controller document, like issuer 21:34:52 `"id": "urn:uuid:"` 21:35:02 mprorock: +1 to uuid, maybe we cover URN in URL examples as well 21:35:16 ... sometimes we like to define schemas in vocabularies 21:35:31 ... sometimes we over URLs, hashes, etc... 21:35:40 ... no blockchain required 21:35:56 ... md5 is till observed in the wild... maybe hashes should be documented? 21:36:08 q+ to talk properties 21:36:13 `digestMultibase` :) 21:36:20 ... should be integrity protect schemas, how? 21:36:29 +1 to using digestMultibase (which includes hash and content type) 21:36:31 ... we should describe what we are seeing in the wild 21:36:40 ack decentralgabe 21:36:40 decentralgabe, you wanted to discuss schemas 21:36:47 decentralgabe: we have one in the CCG 21:37:02 ... there is one in the CCG, I would like to move it into this working group, similar to status list 21:37:03 smccow has joined #vcwg 21:37:07 ... so it can stay in the spec 21:37:09 q+ 21:37:14 smccown has joined #vcwg 21:37:14 ack JoeAndrieu 21:37:14 JoeAndrieu, you wanted to ask if ToS is in both VC and VP 21:37:44 JoeAndrieu: I am in favor of removing things that are not defined... 21:37:53 ... we can use CCG for optional fields 21:38:09 ... we need to remove SHOULD from some of these 21:38:09 I want to revise my proposal for the assurance method. My cognative dissonance was with the term confirmation method which lumped together multiple things. But now that we are using the term "assurance" then the dissonance resolves is we use the NIST terminology precisely which separates Authenticator Assurance Level from Identity Assurance Level. Authenticator Assurance is largely cryptographic whereas as Identity Assurance is not. 21:38:23 ... URLs being here is because of WHATWG... confusion 21:38:34 ... maybe we need to change the guidance on this 21:38:38 q+ 21:38:47 ack kristina 21:39:00 kristina: the property part... status we have a work item 21:39:11 ... credential schema, at risk. 21:39:21 ... refresh service, I am against including it 21:39:36 ... termsOfUse, no strong opinions, it seems at risk 21:39:56 q+ to ask if ToS is in both VC and VP (second time is the charm?) 21:40:04 ... evidence, lots of issues, ccg item exists, but regarding brents original point, we can't spend time on all of this 21:40:21 ... render, seems useful, but maybe we don't need it just yet 21:40:27 ... render seems at risk 21:40:35 ... chair hat off for comments 21:40:38 ack DavidC 21:40:46 q+ 21:40:56 DavidC: Not sure we need to point to standards 21:41:15 ... we don't have any standard terms of use, but we are pointing it at trust infrastructure 21:41:20 ... its using EIDAS trust lists 21:41:23 q+ to note that the objectors asked for demonstrations of interop, not necessarily REC-track documents. 21:41:24 So AA should be an external to the VC data model because it is narrowly defined to be the authentication of the presenter whereas IA should in the data model per subject. So the revised pull request is that we have three constructs. Identity assurance evidence of the Issuers assurance, Issuer recommended methods of identity assurance for the velidator, and issuer recommend methods of authenticator assurance for the validator. 21:41:36 ... does it have to be a standard? seems like the bar is too high 21:41:38 ack dmitriz 21:41:38 dmitriz, you wanted to suggest removing those sections from the spec, and adding a 'reserved terms' section, for future specs. 21:41:59 dmitriz: concrete proposal, we remove these sections from the spec, but then reserve the terms 21:42:12 ... so that we can have seperate specs for each one 21:42:17 gkellogg has joined #vcwg 21:42:18 ack brentz 21:42:18 brentz, you wanted to talk properties 21:42:19 q+ 21:42:41 brentz: our charter does say, for all normative required properties... 21:42:53 @dmitriz very interesting comment! 21:43:03 ... we acknowledged there is a problem here, but it does not mean that we should aim for the low bar we set. 21:43:09 @dlongley - what if we phrase it 'Reserved for future use'? :) 21:43:19 ... lets consider why we are keeping things we can't provide references for 21:43:24 ack Orie 21:43:24 ... agree with dimitry 21:43:27 dmitriz: i'd be worried that DavidC's usage would be invalidated by that language 21:43:27 scribe+ 21:43:59 @dlongley - remind, what usage is that? 21:44:07 orie: notes variations on VC JSON Schema and other ways of linking json schema to credentials and formats 21:44:18 dmitriz: he just mentioned he's using termsOfUse with EIDAS 21:44:20 ... maybe we don't have to point this to a normative standard 21:44:31 ... however at ietf dowrefs are disouraged 21:44:42 q? 21:44:51 ... for good reason to that people are only being directed to stuff that is "real" 21:44:54 W3C allows pointers to specs-in-progress, there just has to be a static, permanent document 21:45:02 @dlongley - he's 'future use'! :) 21:45:04 ... 100% agreement to remove all this stuff 21:45:08 q+ to talk about reserved usage 21:45:15 those pointers can't be normative, however 21:45:16 ... +1 dimitriz 21:45:20 scribe- 21:45:31 ack selfissued 21:45:36 brentz: I understand we have the same notion regardingn Downref 21:45:51 selfissued: its a bit of a tangent, on WHATWG 21:46:09 ... the names are meaningful, and we should maybe not have... since its not great 21:46:11 ack JoeAndrieu 21:46:11 JoeAndrieu, you wanted to ask if ToS is in both VC and VP (second time is the charm?) 21:46:25 +1 dmitriz practical suggestion re: reserved usage 21:46:43 JoeAndrieu: I am a big fan of removing first, and adding good stuff that meets our bar back 21:47:04 q- 21:47:05 +1 to Joe, reserving the terms eliminates the ability to experiment 21:47:06 q- 21:47:07 ... I am opposed to "reserved terms", because it would prevent people from experimenting 21:47:08 so far quite a few folks in favor of removing terms 21:47:19 thank you joe for the reserved comment 21:47:24 ... the question I have is regarding termsOfService 21:47:27 q- 21:47:30 ... is that VC and VP? 21:47:41 if 'termsOfService' is only in VCs, Phil and I will be adding a proposal to adding 'termsOfUse' to VPs 21:47:41 q+ to ask where do we go 21:47:46 ack manu 21:47:46 manu_, you wanted to note that the objectors asked for demonstrations of interop, not necessarily REC-track documents. 21:47:46 ack manu_ 21:47:49 ... doc searl is working on something related to that... maybe its an option 21:48:06 q+ 21:48:08 manu_: the objectors, we spoke to them... they wanted proof there is interop on these things 21:48:18 ... that is a much lower bar than REC or defintion 21:48:21 doc searls' work is over at https://sagroups.ieee.org/7012/ 21:48:28 ... we can just point to CCG things 21:48:29 (user generated terms of service) 21:48:43 audio back inbound 21:48:58 @manu can you repeat your words of wisdom when our audio comes back please 21:49:18 Audio is back 21:49:26 brent has joined #vcwg 21:49:27 ... I think I am -1 to removing things pre-maturely 21:49:42 ... some things seems safe to remove, other seem like we should not remove 21:49:52 q? 21:49:55 ... credential refresh is deployed, we don't want to remove that... 21:50:12 it's in v1.1 21:50:13 ... we would just violate the spec, if we remove things we use in production 21:50:23 nooooooo 21:50:28 render is not simple at all 21:50:30 ... render is simple enough... we should be able to do that in CR 21:50:48 we have a variation of "render" deployed too 21:50:52 ... lets talk about it, maybe this will work. 21:51:26 but it is not simple and it is not only about svg as in PR 21:51:54 @kristina - render /is/ simple as an extension point. 21:51:56 ... status list keep, credential schema lets point to the ccg, refresh service has an implementation and people using it, evidence is ok, termsOfUse seems poorly supported currently 21:51:58 q+ 21:52:06 for render, at least just point to a spec in DIF, no reinventig please 21:52:07 ... is anyone using termsOfUse? 21:52:14 DavidC: We used it in tests 21:52:27 ... it communicates trust framework 21:52:38 ... if you demonstrated interop, then it stays 21:52:41 ack brent 21:52:41 brentz, you wanted to ask where do we go 21:52:56 @kristina - that is what the paper proposes, fwiw. https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/draft-documents/rendering-vcs-snapshot-9-27-22.md (using existing specs like DIF) 21:52:58 refresh has been causing a lot of confusion 21:53:08 brentz: If there is something on this list, that you are using, will you raise a PR to modify the spec to point to something? 21:53:18 link to "this list"? 21:53:22 there is a number of ppl that use credentialSchema with JSON schemas 21:53:32 ... slide 72 21:53:33 tnx 21:53:46 +1 oliver -- Open Badges v3 uses credentialSchema w/ json schema 21:53:58 ... we need to concretly move forward 21:54:03 q+ 21:54:16 ... seems people want to do things, but will they open PRs? 21:54:20 q+ 21:54:25 ack mprorock 21:54:30 list of issues with ready for PR: https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+label%3A%22ready+for+PR%22 21:54:44 mprorock: The danger of reserved, sounds great, but ... maybe its not a good solution 21:54:55 q- 21:54:55 +1 Oliver, so does CLRv2 from 1EdTech and they have for both OBv3 and CLRv2 at least four commercial vendors committed to implement it. 21:55:01 ... it seems reasonable to clarify language on URLs 21:55:08 ... I will maybe open a PR 21:55:32 q? 21:55:34 ... implied by the core of what we do is status, the other items, maybe we should drop the rest 21:55:38 ... they can be used 21:55:46 ... they don't need to be pointed to CCG docs 21:56:13 ... CCG is awesome place to incubate, but it doesn't seem like a good place to point to... for the single reference for TRs 21:56:13 q+ to ask Manu about evolving the spec and decentralized vocabulary 21:56:20 q+ having extension points doesn't meant you have to define all the extensions. 21:56:27 q+ to note that having extension points doesn't meant you have to define all the extensions. 21:56:30 ... anywhere we are considering to pointing to the CCG, seems dangerous to the work... 21:56:51 ... we can recharter to cover items, lets not use the CCG to cover overflow 21:57:07 gkellogg has joined #vcwg 21:57:10 ack DavidC 21:57:13 zakim, close the queue 21:57:15 ok, kristina, the speaker queue is closed 21:57:23 ack DavidC 21:57:25 DavidC: I covered termOfUse 21:57:26 ack Paul_Dietrich_GS1 21:57:31 ack Paul_Dietrich_GS 21:57:34 ack Paul_Dietrich_GS 21:57:40 Paul_Dietrich_GS1: was there any conclusion on dereference URLs vs non dereference? 21:57:46 -1 to creating an artificial problem here -- people are using things and if that rises to the level of interop needed by previous objectors, we should not remove things and create chaos/trouble. 21:58:00 q+ to propose we define 'VC Extension Mechanism' once, in a section, since we're using the exact same mechanism anyway. and then list terms that fall under that. 21:58:03 we have enough other real issues to address. 21:58:08 brentz: We seem to want to clarify URL vs URN as legal for use cases 21:58:11 what if we define 'VC Extension Mechanism' once, in a section, since we're using the exact same mechanism anyway. and then list terms that fall under that. 21:58:21 q+ 21:58:57 q? 21:59:32 mprorock: we can cover cases for both URL and URN, DID etc... 21:59:41 ... we can provide better language 21:59:43 https://github.com/w3c/vc-data-model/issues/914 21:59:45 @dmitriz I believe that's already defined in https://www.w3.org/TR/vc-data-model/#extensibility 21:59:48 ack JoeAndrieu 21:59:48 JoeAndrieu, you wanted to ask Manu about evolving the spec and decentralized vocabulary 22:00:04 JoeAndrieu: We should back away from WHATWG 22:00:09 ... it breaks file URLs 22:00:12 @andres - oh right! 22:00:20 ... so seems like we should not follow that guidance 22:00:32 also a bit related: https://github.com/w3c/vc-data-model/issues/709 22:00:41 ... question for Manu, no snark implied 22:00:45 and this kind of https://github.com/w3c/vc-data-model/issues/945 22:01:10 ... my understanding is that your current VCs won't break anything, because you already cover this use case under 1.1 22:01:12 https://url.spec.whatwg.org/#example-url-parsing <-- some examples of valid file URLs are in there 22:01:14 ack manu_ 22:01:14 manu_, you wanted to note that having extension points doesn't meant you have to define all the extensions. 22:01:18 q? 22:01:24 manu_: Do we want to open that can of worms 22:01:38 ... it is true that 1.1 context, will perserve terms that are dropped 22:02:03 ... some folks won't be insulated from breaking changes 22:02:17 -1 that v1.1 will be affected, the JSON schema would still check the literal context values 22:02:17 ... why are we trying to do work that was not asked for by objectors 22:02:28 because it's not about formal objections 22:02:44 PR to add a schema reference https://github.com/w3c/vc-data-model/pull/1042 22:02:48 ... the reason we added extension points, was to allow people to use them 22:03:01 mprorock: we don't have requirements for this 22:03:02 +1 22:03:17 manu_: we don't need to describe anything, just let people use the extension points 22:03:19 +1 to Manu ... stop messing with people that are doing useful things :) 22:03:51 we are actively using ToU 22:03:52 ... concern is that we are solving a non problem 22:06:37 Lets try to raise some PRs 22:06:58 i wish i was there :'( 22:15:24 gkellogg has joined #vcwg