Verifiable Credentials Working Group F2F, 1st day — Minutes
Date: 2023-02-14
See also the Agenda and the IRC Log
Attendees
Present: Ted Thibodeau Jr., Kaliya Young, Kristina Yasuda, Oliver Terbu, Ivan Herman, Manu Sporny, Dave Longley, Andres Uribe, Geunhyung Kim, Brian Campbell, Gabe Cohen, Phillip Long, Brent Zundel, Michael Prorock, Joe Andrieu, Michael Jones, David Waite, Shigeya Suzuki, Mahmoud Alkhraishi, Will Abramson, Markus Sabadello, Samuel Smith, Przemek Praszczalek, Paul Dietrich, Dmitri Zagidulin, orie Will, Drummond Reed, Steve McCown
Regrets:
Guests: Phil Fariller, Kevin Griffin, Paul Bastian
Chair: Kristina Yasuda, Brent Zundel
Scribe(s): Manu Sporny, Michael Prorock, Gabe Cohen, Will Abramson, Orie Steele
Content:
Andres Uribe: we have to make sure folks in miami aren’t simulated.
Brent Zundel: Welcome everyone!.
… We have a code of conduct, we’re under the new patent policy.
… here is today’s agenda – content types, holder binding, vc extension points, terminology..
… We’re going to dinner around 5:30pm.
Andres Uribe: slide set: https://docs.google.com/presentation/d/128DHWSzVxPgAhB0mq-h23_iATnbVeA4Y-JhNLjpcXJE/edit#slide=id.p1.
Phillip Long: Phil-ASU has joined #vcwg.
Kristina Yasuda: holder binding conversation will be from 1:15pm no matter what - because we have ppl from NZ joining.
Ted Thibodeau Jr.: Quick request, individual presentation decks added to master deck, please..
Brent Zundel: Reminder, the VCWG mission is to make expressing, exchanging, and verifying credentials easier and more secure on the web..
… We have a list of normative deliverables and status….
… This is a lot of deliverables, the Technical Report Process applies to all of those items..
… The process goes from WD to CR to PR and then Recommendation..
… Once we address all issues we can keep going forward….
… Once we make substantive changes to CR, we have to start process again..
Manu Sporny: brent reviews the standard timing of our primary spec..
Brent Zundel: timeline is to be done in may 2024, CR2 by Jan 2024, CR1 by Sept 2023, March 2023 feature freeze..
… You can change scope after you go into feature freeze – we defined the scope..
… Doesn’t mean we’re done, we’re done talking about what we’re working on..
… 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..
Mahmoud Alkhraishi: Do all documents need to go through this process?.
Samuel Smith: What if we wanted to add a new document or a change/addition?.
… What about vc-ac-dc?.
Brent Zundel: 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..
Samuel Smith: Assuming we have the resources to do the work?.
Brent Zundel: 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..
… For the main spec, feature freeze..
… for other normative deliverables, a solid timeline for CR..
… For non-normative deliverables, a full understanding of the set of work for each..
… We could possibly recharter to work on items we don’t get to…
Samuel Smith: 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..
Brent Zundel: Feature freeze I’m talking about is for main spec… for every other normative deliverable, what’s the plan for getting to CR..
… We have a lot of work going on in parallel, we need to have a good understanding for non-normative things..
… With that, introductions…. or questions..
1. Introductions.
Brent Zundel: We’re going to do introductions now… the question that was always asked to the group is one that I will ask of you..
… Your name, who you’re representing, your favorite breakfast cereal, if your feet could taste, what flavor would you want your socks to be..
… 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..
Kristina Yasuda: Hi Kristina Yasuda, work for Microsoft, breakfast cereal – crave (in europe chocolate biscuits)… favorite sock would be no smell socks..
Oliver Terbu: Oliver Terbu, from Spruce, identity startup, favorite breakfast cereal (shakshuka), no opinion on socks..
Manu Sporny: Manu Sporny, Digital Bazaar, sardines and hummus, green apple socks..
Samuel Smith: Sam Smith, work for startup studios, raisin bran and sock flavor lemon coconut..
Phil Fariller: Phil Fariller, GLEIF, lucky charms and blueberry socks…
Joe Andrieu: Joe with Legenday, golden grams, mint green tea..
Przemek Praszczalek: Przemek, from Mastercard, cybersecurity and intelligence, cream of wheat with honey, roasted garlic saurkraut for socks..
KevinGriffin: Kevin Griffin, GLEIF, frosted cereal, bacon socks, please..
Shigeya Suzuki: Shigeya Suzuki, KEIO University, bagel with cream cheese, no smelly socks..
Paul Dietrich: Paul Dietrich, GS1, strawberry frosted pop tart, mint or citrus socks..
Will Abramson: Will Abramson, Legendary and Digital Contract Design (today), muselix, mountain spring water socks..
Michael Prorock: Mike Prorock, Mesur.io, southeast asia noodle dish, neutralizing socks..
Orie Steele: Orie Steele, Transmute, DIDs and VCs, no cereal or socks..
Gabe Cohen: Gabe from TBD/Block, french toast crunch, socks ginger to reduce nausea of everyday life..
DavidW: David Waite from Ping Identity, nice omlette, strawberry lemonade socks..
Mahmoud Alkhraishi: Mahmoud, Mavennet, flat bread w/ cheese, chocolate socks..
Michael Jones: Mike Jones from Microsoft, identity and security standards, crispix with fresh blueberries, if my feet could taste my socks need to be mango lassi..
Andres Uribe: Andres from TBD/Blck, work with Gabe, arepa with cheese and fried egg, sock flavor key lime pie..
Brian Campbell: Bian Campbell, work with Ping, frosted mini wheats and recuse from foot tasting declarations..
DaveLongley: Dave Longley, Digital Bazaar, banana bread, chocolate socks..
Dmitri Zagidulin: Dmitri Zagidulin, DCC, oatmeal or golden grams, neutral sock flavor..
GyhunHeungKim: Gyeun Heung Kim from Gooroomee, omlette and no sock options..
Ivan Herman: I am W3C staff contact, I mix all kinds of nuts for breakfast with yoghurt, no idea about my feet.
Kaliya Young: Kaliya Young, IdentityWomanInBusiness, invited expert, favorite cereal grain free granola w/ yogurt, seaweed socks..
Markus Sabadello: Markus Sabadello, Danube Tech in Vienna, favorite breakfast cereal corn flakes with milk, corn flake socks too.
Dmitri Zagidulin: 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 :) ).
Phillip Long: Phil Long, Arizona State, haitian blue coffee socks..
Ted Thibodeau Jr.: Ted Thibodeau, Openlink Software, bacon eggs toasted english muffin, watermelon socks..
Brent Zundel: Thank you for tat, that was excellent..
2. Content Types.
See github pull request vc-data-model#1014.
See github pull request vc-jwt#51.
Ivan Herman: slides starting at: https://docs.google.com/presentation/d/128DHWSzVxPgAhB0mq-h23_iATnbVeA4Y-JhNLjpcXJE/edit#slide=id.g1f24e2c0aad_14_271.
Orie Steele: We’re going to be talking about content types and media types..
… 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..
… 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..
… We should be cautious to heed these warnings….
… Where are media types registered? Look at previous examples, excellent IETF mailing list for every type of media types..
… You can learn a lot from those registrations..
Ted Thibodeau Jr.: 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..
Orie Steele: They typically register because they want to distinguish content… there is a registry, it has useful entries, large number of existing registry entries..
… 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).
… 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)..
Brian Campbell: there’s also the Structured Syntax Suffixes registry.
Kristina Yasuda: time to register +ld.
Orie Steele: 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..
… oauth2 – http endpoint using application/json – might want to declare content type… might want to define HTTP.
… 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..
… One of the useful things about media types and content types and describe constraints… naming can be hard..
… media types are a good way of describing content and attributing content w/o getting tied up….
Michael Jones: I’m excited about application/json because it does a lot of heavy lifting every day..
Orie Steele: 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 content types..
… 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..
… Returning different content types for same resource can be helpful..
… 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..
… 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..
… application/credential+ld+json – here’s where the debate starts… is proof allowed? We haven’t registered this yet, it’s proposal at present..
… We could change the proposal at any point..
Mahmoud Alkhraishi: What’s the timeline on te proposal?.
Orie Steele: 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….
Ivan Herman: 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..
Michael Prorock: +1.
Brian Campbell: +1 can and does happen.
Michael Jones: 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 something wrong. What we would be asking for at CR is a provisional recommendation, it does appear and it appears as “temporary”… once we have a REC, at that point we send another request to IANA to update registration from provisional to permanent..
Ivan Herman: +1 to Mike.
Ivan Herman: +1 to TallTed.
Michael Prorock: +1 ted.
Ted Thibodeau Jr.: 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 accepted, otherwise it gets rejected.
… then we’ll have to figure that out at that point..
Samuel Smith: could’t we use a specific parameter to provide the extra information that a double plus content type provides without having to wait for RFC to allow double pluses?.
Manu Sporny: rfc for multiple pluses is in good shape and getting ready for last call.
Shigeya Suzuki: FYI: https://datatracker.ietf.org/doc/draft-ietf-mediaman-suffixes/.
Orie Steele: 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..
… What are the constraints, how can this be processed consistently, we want to be clear – it’s definitely alowed, or definitely disalloewd..
… 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 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?.
… 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, just the threads can get long..
… This is a conversation about v2.0 and beyond, but there ar other pieces where we will talk abou tthe past. Talking about v1.1 vs. v2.0.
Samuel Smith: 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..
Orie Steele: 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..
Andres Uribe: +1.
Orie Steele: 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’.
Brian Campbell: see https://www.iana.org/assignments/jwt/jwt.xhtml.
Michael Jones: JWT Claims Set is defined by the JWT specification RFC 7519.
Michael Jones: The JWT Claims Registry is at https://www.iana.org/assignments/jwt/jwt.xhtml.
Orie Steele: 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..
… 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..
Michael Jones: 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..
Kristina Yasuda: JWT Claims Set: A JSON object that contains the claims conveyed by the JWT..
Michael Prorock: 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”….
Orie Steele: 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..
Michael Jones: 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… It was fixed IE at one point, it’s bigger than it used to be, you have systems truncating content..
Orie Steele: To make the token format, you can make a string encoding on top of another string encoding.
Michael Jones: By a factor of 33% larger.
Orie Steele: 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..
Samuel Smith: 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..
… What you’re proposing is using contnet type to indicate that you’re tunnelling something else inside claim set?.
Orie Steele: 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..
… 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..
Samuel Smith: This one is saying proof is externally attached..
Orie Steele: Yes…
… 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..
Mahmoud Alkhraishi: https://w3c.github.io/vc-jwt/#jwt-encoding paragraph 2.
Kristina Yasuda: found the statement, if JWS is present, digital signature applies to issuer… or VP … is a holder..:
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.
If no JWS is present, a proof property MUST be provided..
Mahmoud Alkhraishi: https://w3c.github.io/vc-jwt/#jwt-encoding paragraph 3.
Orie Steele: It says “can be omitted”, doesn’t say “MUST” be omitted. What we would interpret that as is proof is optional..
Michael Prorock: +1 one of the many issues in 1.1.
Kristina Yasuda: 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..
Orie Steele: At this point, we should read definition of credential and verifiable credential..
Joe Andrieu: I don’t know if this is substantive, is type after @context, are they scoped by VC?.
Dave Longley: 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.
Kristina Yasuda: “ a proof not based on digital signatures, such as Proof of Work” wow.
Michael Prorock: yeah. some things that really need professional improvements in 2.0.
Oliver Terbu: 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..
Kristina Yasuda: > 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..
Orie Steele: This is probematic language in v1.1, definition of credential and verifiable credential uncomfortable and confusing to readers..
Brent Zundel: A credential is a set of one or more claims made by an issuer. A verifiable credential is (reads from spec)….
Kristina Yasuda: can we please remove “authorship” from definition? it’s weird…
Michael Prorock: i want to find the time to do a verbiage / editorial pass soo soo badly.
Kristina Yasuda: can we not user
vcanymore in a vc-jwt….
Kristina Yasuda: in v2 i mean.
Orie Steele: 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 ….
Oliver Terbu: +1 kristina.
Ted Thibodeau Jr.: 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..
Kristina Yasuda: (continue after break…).
Orie Steele: how many media types do we have defined right now? … 0 in v1.1, 1 currently in the proposal.
… 1 defined so far. credential+ld+json … see 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..
… 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.
… 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.
… underway in describing the relationship between the two. vc-jwt has a PR open. data integrity does not have a PR yet..
… secured by data integrity, has the content type ‘riding along with it’ - different approaches. we are required to describe both cleanly for good impls.
Joe Andrieu: 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.
Orie Steele: 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.
Ted Thibodeau Jr.: https://github.com/w3c/vc-data-model/pull/1014/.
Orie Steele: 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..
… 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.
Michael Jones: typ is what you would put in a browser if you were to transmit.
Orie Steele: cty is about the payload alone, not header or signature.
… 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.
Kristina Yasuda: PR 51 in vc-jwt, not merged yet.
See github pull request vc-jwt#51.
Michael Prorock: 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. just the rules around it..
Orie Steele: that’s right. spice from the first slide!.
Ted Thibodeau Jr.: 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..
… not the standard use of media types. will cause confusion if trying to use them now.
Orie Steele: can someone read the section that describes the removing of the application prefix? TallTed is right..
Kristina Yasuda: See https://www.rfc-editor.org/rfc/rfc7515#section-4.1.9.
David Waite: 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…
Manu Sporny: 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..
Ted Thibodeau Jr.: the key question is “what happens if devs get it wrong?”.
Manu Sporny: “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?.
… 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.
… 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.
Orie Steele: 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..
Ivan Herman: A warning about the practicalities of media types is in https://mimesniff.spec.whatwg.org/#introduction ….
Orie Steele: 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..
Dave Longley: browser vendors probably won’t parse any of these media types in the near future :).
Orie Steele: 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.
Dmitri Zagidulin: 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.
Dmitri Zagidulin: 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).
Michael Prorock: 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.
Ivan Herman: +1 to mprorock.
Dmitri Zagidulin: (n/m, I take back that comment. it’s all transforms.).
Michael Prorock: 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.
… is this possible? is it valuable in certain cases?.
Michael Prorock: +1 kristina.
Kristina Yasuda: 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..
Dave Longley: +1 to there being value in both signing “the presentation bytes” and in signing “the semantic bytes”.
Michael Prorock: 1+ to point out what typ and cty are saying in this example.
Dave Longley: different use cases need one or perhaps even both.
Kristina Yasuda: 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.
Samuel Smith: 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..
Michael Prorock: yes.
Michael Prorock: +1 selfissued.
Michael Jones: 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.
Gabe Cohen: ere will be sets that don’t make sense - need to validate one’s inputs always, that’s always true.
Michael Jones: appreciate how differentiating things that are actually different has enabled us to make progress.
Joe Andrieu: 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..
Dmitri Zagidulin: (to Joe’s point – I think Orie’s earlier point was – we /could/ specify integrity separately, as a Content Type param).
Joe Andrieu: however things get secured, will need to add it for both VCs and VPs..
Ted Thibodeau Jr.: maybe consider a media type parameter, like
Content-Type: application/vc+ld+jwt; integrity="whatever".
Samuel Smith: 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.
… can say as a part of normative requirements. need to do validation for semantics/schema.
Ted Thibodeau Jr.: I don’t know if multiple parameters are viable….
Dmitri Zagidulin:
@SamSmith- we do have that right now, no? with the credentialSchema claim?.
Michael Prorock: 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.
Samuel Smith: @dmitriz But what are the normative rules for applying that credentialSchema claim. And should that be in the header metadata?.
Michael Prorock: 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..
… 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.
Orie Steele: 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..
Dmitri Zagidulin:
@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.
Orie Steele: 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.
Gabe Cohen: Orie could be relevant to devices that are constrained, don’t have libs to process, or just forwarders.
Michael Prorock: +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).
Orie Steele: can close door to some use cases being affected if we do this.
Dave Longley: 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.
Ted Thibodeau Jr.: +1 dlongley – only as many media types as necessary.
Dave Longley: 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.
Manu Sporny: +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..
Kristina Yasuda: what is “media type pattern”..?.
Manu Sporny: … 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)?.
Dave Longley:
typfield is recommended best practice these days for JWTs.
Samuel Smith:
@dmitrizI 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..
Manu Sporny: 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..
… 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?.
Orie Steele: intention not to make any decisions during the f2f, just to inform.
Brent Zundel: let’s make decisions!.
Michael Prorock: awesome question.
Andres Uribe: 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 lot for devs.
Orie Steele: 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.
Mahmoud Alkhraishi: 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?.
Orie Steele: 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..
Michael Prorock: all of this discussion is only really in the context of JWTs.
Orie Steele: 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.
Michael Prorock: typ isn’t really a thing you can assume exist in other presentation or exchange methods.
Mahmoud Alkhraishi: when I’m processing vc+ld+jwt am I expected to process two signatures?.
Orie Steele: that’s the warning!.
Joe Andrieu: 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.
… checking multiple = creating problems.
Brent Zundel: what decisions do we want to make here? PR #1014 proposes to say proof is not included, right?.
Orie Steele: 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..
Dave Longley: that’s correct, a verifiable credential is also a credential, it is a subclass of it..
Dave Longley: not to mention that
proofmay have many different kinds of proofs in it and so on..
Orie Steele: 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.
Brent Zundel: also a decision to be made for #51?.
Orie Steele: yes, for #51 we are requesting the registration for typ parameter in vc-jwt. it is JWT specific. #1014 is core data model specific.
Dave Longley: 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?.
Brent Zundel: in addition to those two decisions, what other proposals could/should be on the table for the group for the next 30m?.
Ivan Herman: +1 to dlongley.
Orie Steele: other proposal: application/vc+ld+cwt..
Dave Longley: we get to decide if it makes sense if squares are rectangles in this case :).
Andres Uribe: I would propose adding a media type:
application/vc+ld+json;proof={embedded,jwt,cwt}.
Dave Longley: decentralgabe: they already are :) … we’d have to change the VCDM. … and it would be very confusing to decide the opposite..
Dmitri Zagidulin: @andres - nice, +1.
Ted Thibodeau Jr.: 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..
Dave Longley: +1 to TallTed.
Michael Prorock: 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..
… 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).
… 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.
… this kind of confusion is what we’ll get into. get into weird stuff.
Manu Sporny: 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+
Kristina Yasuda: i think this is the current situation: https://hackmd.io/Q8EOfbzYTZK_jHH-BJcfKA?view.
Kristina Yasuda: wrt all of the media types proposed.
Manu Sporny: 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..
… from the LD side, just need those two media types: credential+ld+
David Waite: 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.
Dmitri Zagidulin:
@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.
Dmitri Zagidulin: type-related property, and we already have 2, which is too many :).
David Waite: 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.
… 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.
Joe Andrieu: 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.
Gabe Cohen: +1 JoeAndrieu.
Kristina Yasuda: reviewing document posted above (https://hackmd.io/Q8EOfbzYTZK_jHH-BJcfKA?view).
Orie Steele: do not have any merges for typ in the core data model just yet.
Kristina Yasuda: Manu’s proposal in typ not cty.
Samuel Smith: q.
Michael Jones: 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..
… 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.
Samuel Smith: q.
Orie Steele: [new slide - 25] Pull #51 in vc-jwt has both vc+ld+cwt and vc+ld+jwt.
… 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.
Andres Uribe: 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.
Joe Andrieu: FWIW, I added a concrete parameter suggestion in the PR https://github.com/w3c/vc-data-model/pull/1014#issuecomment-1430076799.
Dave Longley: 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.
Gabe Cohen: ould not be too prescriptive. can harm legitimate use cases and violate expectations around subclasses.
Ted Thibodeau Jr.: +1 Use Cases -> Requirements -> satisfy those requirements.
Dave Longley: -1 the openssl and x.509 CVEs are not a concrete use case, it does not apply, this is not binary data.
Orie Steele: 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?.
Michael Prorock: 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..
… 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.
… 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..
Samuel Smith: 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.
… 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.
Manu Sporny: clarification there is no +ld media type. does not exist. it is only ld+json. would need to figure out something….
… 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.
Brent Zundel: Dave mentioned squares and rectangles. Let’s talk about the accurate labeling of squares and rectangles..
… 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.
Mahmoud Alkhraishi: 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.
Dave Longley: +1 that the processing rules for vc+ld+jwt could say you may not have the proof is fine / or define whatever.
Mahmoud Alkhraishi: 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..
… what are the downsides to this approach?.
Dave Longley: if we’re deciding to add a prohibitive statement let’s be clear about what problem it’s solving with a concrete use case..
… 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.
Dmitri Zagidulin: so did somebody propose media type param approach, for proofs?.
Orie Steele: 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.
… 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.
… this structure isn’t out of nowhere. others are talking about doing this.
Mahmoud Alkhraishi: first here means ctyp second here means right side of the screen.
Orie Steele: 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).
… having both present leads to a behavior with mixed verifiability.
Michael Prorock: 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?.
… 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..
Joe Andrieu: 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..
Manu Sporny: 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..
Kristina Yasuda: why can’t we prohibit, and wait until people tell us they need it?.
Manu Sporny: 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.
Dave Longley: +1 to manu’s approach.
Samuel Smith: 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..
… 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..
Ivan Herman: is it verifiable+credentials+ld+json or verifiable-credentials+ld+json ? These are very different.
Michael Prorock: +1 ivan very different.
Gabe Cohen: 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..
Kristina Yasuda: why would you send those statusList VCs in a VC(?) tho.
Brent Zundel: it is vc+ld+son.
Kristina Yasuda: in the spec rn - verifiable-credentials+ld+json.
Brent Zundel: +1 kristina.
Kristina Yasuda: i mean
verifiable-credential+jwt.
Michael Prorock: different between verifiable+credential and verifiable/credential.
… should get agreement.
Ivan Herman: I am talking about jwt, but about, say, cty.
Michael Prorock: sure on jwt space - but then what about things like vc-api and “what am i asking to sign and what am i returning”.
Dave Longley: 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.
Michael Prorock: that also implies that we may not want this stuff in the browser.
Michael Prorock: i certainly do.
Orie Steele: 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.
… 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.
… verifiable-credential and credential can be wildly different in ways that are horrendously confusing.
… they can be related…or we can explicitly not register verifiable-credential because it’s confusing. review comments on #1014!.
Michael Prorock: 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?.
… 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.
Kristina Yasuda: @decentralgabe are you sending those in a VP or a VC?.
Dave Longley: -1 to everything is Mike saying :) … credential+ld+json will just not have any proofs processed by default by browsers, the end :).
Kristina Yasuda: if in a VP, no need for tunneling, no?.
Kristina Yasuda: each VC is signed using its own way, and VP is signed using one way.
Dmitri Zagidulin:
@manu- do you think Google et al will support using media type parameters, for proof types?.
Manu Sporny: all vendors support application/ld+json. tell vendors do things as you’ve always been doing..
Dmitri Zagidulin: don’t VPs need their own media types?.
Manu Sporny: yes, probably :).
Ivan Herman: (lunch break.
3. Holder binding.
Ivan Herman: Slides start at https://docs.google.com/presentation/d/128DHWSzVxPgAhB0mq-h23_iATnbVeA4Y-JhNLjpcXJE/edit#slide=id.g1f24e2c0aad_14_5.
Oliver Terbu: Session about holder binding.
… multiple issues about this in vcdm.
… slides by oliver and DavidC. Don’t both agree fully.
… slides note agreement.
… 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.
… second prob statement in slide from oliver relates to confirming the VP..
… slides will clarify this prob statement.
… oliver to present before taking Qs.
Samuel Smith: Why not just have a metadata field labeld “issuedTo” whose value is a cryptonym (cryptographically derived identifier) with similar security properties for the identifier of the “issuedBy”.
Oliver Terbu: assumptions - issuer should never know who the verifier is.
Dave Longley: SamSmith: that is one of the ideas being thrown about as a possible solution / partial solution, to my knowledge.
Oliver Terbu: isuer may attempt to control the use of VC through termsOfUse.
… but binding is a claim made by issuer about subject.
… isuers are trusted, if not then VCs should not be accepted by verifier.
… meaning if issuer includes confirmation methods in VC the verifier can trust these.
… evidence property doesn’t cover this use case.
… confirmation method definition on slide 31 of the deck.
Samuel Smith:
@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..
Oliver Terbu: a conf method could be a cryptographic identifier or key.
… trying to come up with standard mechanism for this.
… feedback from ccg is that any property of subject of VC could be used to determine if presenter is subject of presented VC.
… though in certain cases e.g. zkp bases there aren’t many useful properties in credSubject.
… issuer does not need to tell verifier what properties to use. Up to the verifier.
… need mechanisms to make the verifiers life easier.
… RWOT paper on holder binding. Although became clear term is confusing.
… subject not always holder.
… holder binding misleading as used in different contexts.
… rwot paper proposed identifier binding term.
Dave Longley: +1 that “identifier binding” is better than “holder binding”.
Dave Longley: (maybe still not “the best” possible name, but better).
Samuel Smith: 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.
Oliver Terbu: Definition of identifier binding found in slide 34.
… paper uses a simple use case.
… more realistic might be from the EU digital wallet initiative. e.g. esim, online prescriptions etc.
… paper use case looks at three variations of a course offering. Remote async, remote sync and inperson.
Manu Sporny: is the trevor use case a malicious one.
Oliver Terbu: no, in some cases gov want to enable “friendly fraud”.
… looking at the fully remote scenario first.
… one cred “second order logic” contains only the information that some identifier passed the course Second Order logic. That is it.
… on its own, not that useful.
Samuel Smith: 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..
Oliver Terbu: might add some pii to the credential subject. e.g. name.
… possible to use this VC for in person verification. e.g.alice brings passport to course.
… but looking at fully remote usecase.
… Alice could prove control over a key, and this can be included into the VC.
… could add publicKey or VM property to VC. But not clear to verifier how to interpret this.
Dave Longley: 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.
Oliver Terbu: propose new property - binding in paper.
… can bikeshed term later.
… I like confirmationMethod.
… this property makes clear the semantics.
… only with collusion could someone use the cred who wasn’t the subject.
… proposal VCDM should define a few simple binding types and support an extension mechanism for new types to be added.
… This might work for biometrics too.
Paul Bastian: working on Eidas, interesting in holder binding. Started in DIF wallet security..
Oliver Terbu: application of this are any where you need specific assurance or confidence to prevent identity fraud.
… Other systems use similar approaches. ISO mDoc, AnonCreds etc.
… There are some privacy considerations, these are similar to those in the VCDM.
Paul Bastian: 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.
Oliver Terbu: should be increased focus on selective disclosure for the property, as might include PII.
… verifiers can use other claims in credential aswell.
… there is a second part to this.
Kristina Yasuda: concretely this proposal about putting “binding” property into VCDM.
Dave Longley: originally got in queue to suggest refine problem statement. To rule out collusion.
… should be explicit whether or not we are trying to cover this case.
… maybe we are trying to cover these collusion use cases.
… be explicit what we are protecting against.
… maybe not about binding, but rather what is provable.
… provable.
Samuel Smith: agree we should have strong binding methods. There is many legit usecases when presenter is not the subject.
… presenter designation should be metadata to the claims.
Michael Prorock: that feels like combination of terms of use and other areas covered.
Samuel Smith: Need to have an issuedTo as additional metadata.
… we can simplify complexities by moving designated presenter to metadata. Show link by having id of subject to this presenter in metadata.
Dmitri Zagidulin: Understand the usecase. Holder binding firmly belongs in termsOfUse property. Issuer dictating how cred should be used.
Orie Steele: See https://w3c.github.io/vc-data-model/#terms-of-use.
Dmitri Zagidulin: want to comment on publicKeyMethod. that is just redefining the DID spec. We already have a way to do this..
Michael Prorock: there is this cool did:jwk thing too ;).
Dmitri Zagidulin: if you are saying we don’t have a way to use dids with vcs we should fix that.
… The idea to restrict VCs to certain wallets is horrifying. Users should be able to transfer creds between wallets. Key part of VCs.
… whole trust model has to do with keys and not the wallet.
Kristina Yasuda: some use-cases require HW bound keys.
Manu Sporny: these are valid usecases.
Kristina Yasuda: so no moving between the wallets.
Michael Prorock: +1 hw keys.
Manu Sporny: Discussion is around where this goes in data model.
Kristina Yasuda: progress that we agree that we want this mechanism in vcdm.
Manu Sporny: We have a mechanism to do key authentication - DID auth. Still need to connect some docs.
… This probably shouldn’t go in the credSubject.
Dave Longley: “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..
Manu Sporny: So where does it go - possible termsOfUse.
Kristina Yasuda: not all use-cases use didauth.
Michael Prorock: +1 kristina.
Michael Prorock: most don’t.
Dmitri Zagidulin:
@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.
Manu Sporny: not everything uses did auth, but that does exist.
… this is about using alternate binding schemes other that DID auth. That is legitimate..
… need to do something about it, but need to consolidate with preexisting work.
Dave Longley: binding isn’t about restricting behavior, it’s about linking two (or more) things together – and we should be careful about that..
Brent Zundel: In general, if proposing a new extension method we need at least one normative way to do this.
Kristina Yasuda: 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.
Brent Zundel: Need to define at least one way to use this property.
Manu Sporny: agreed, I don’t think anyone is saying “DID Auth is the only way to authenticate”.
Brent Zundel: credentialSubject property can have as many subjects as you want.
… This is a way of securing a VC, from a specific viewpoint.
Dmitri Zagidulin:
@manu_- I mean.. I’m sort of saying that why are we introducing developer confusion by having two ways of using key-based auth?.
Brent Zundel: We could move holder binding proofs in proofSection. This could be a separate spec.
Samuel Smith: +1 to holder binding being in the proof not inside the body of the VC.
David Chadwick: I have four points.
… oliver said evidence should be out of scope. I disagree, some info should go in this property.
… I think paper confused identifier with identity.
… One interesting way this could be used is if vc method is an x509 distinguised name.
… Seems these were all use cases of the nonTransferable property.
… Therefore its a terms of use feature.
Kristina Yasuda: WG seems to disagree on 1/how to call this; 2/where to put the information.
Manu Sporny: perhaps if we could focus in on a non-controversial use case?.
Dave Longley: 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.
Kristina Yasuda: termsofuse, nontransferrable, credentialsubject, evidence.
Paul Bastian: no the usecases in the paper include transferable VCs.
Samuel Smith: 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.
Joe Andrieu: I like this approach. The paper does a great job trying to understand the problem before solving it.
Michael Prorock: big +1 Joe - seriously hard work here.
Joe Andrieu: I don’t like termsOfUse or nonTransferable. These imply control structures.
… to me, a VC is an uttered statement. I care about who uttered it and if they still stand by it.
Kristina Yasuda: would love to agree how the property will look like, before we debate where to put.
Joe Andrieu: We do have DIDs and auth mechanisms for DIDs, but we don;t have this for any other uris.
Samuel Smith: +1 to JoeAndrieu for its a control structure -1 that we don’t need control structures..
Joe Andrieu: I like shift from binding to confirmation btw.
Dave Longley: 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.
Joe Andrieu: How do we specify how you authenticate for a credSubject that identify an entity using a twitter url for example.
Kristina Yasuda: wg also agrees the mechanism is optional.
Kristina Yasuda: to summarise, lets focus on where we want to put this property and what it will look like.
… we have a bunch of options, lets move things forward.
Oliver Terbu: dmitriz in my opinion this property is a claim made by the issuer about the credentialSubject.
… This is a valid claim.
Dmitri Zagidulin: -1 oliver. it’s a credential claim..
Oliver Terbu: We are not saying this can go in a single wallet.
Kristina Yasuda:
@dlongley“property” might have been a wrong word - more like structure, but at the high level, sure :).
Dave Longley: :).
Oliver Terbu: We are not trying to redefine DIDs, it was just an example.
Dave Longley: saying some entity has some identifier (an identifier with this special cryptonym-like property) makes sense in the
credentialSubjectto me … saying more about ways to authenticate / get identity assurance and so on could easily belong somewhere else..
Brent Zundel: it’s a claim about how a subject relates to a credential, so it could validly fit in either place.
Oliver Terbu: 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.
Kristina Yasuda: confirmation method seems to be dominant one that people agree with…
Oliver Terbu: Better to define a single place for this information.
… Really challenging to implement this use case today.
… to SamSmith yes this is a simplification. It is a good one. Makes it simpe to implement.
… I also fully acknowledge there might be other roles that need to be defined..
… don’t like to proof section approach.
Dmitri Zagidulin: 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.
Brent Zundel: this proposal does support multiple credentialSubjects. This is one reason this should go in cred subject.
Dmitri Zagidulin: validUntil is also a claim. but it doesn’t belong in subject.
Samuel Smith: 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..
Orie Steele: I can imagine a scenario with evidence, proof, termsOfUse and 6 subjects, 5 bound to keys and 1 bound to a human subject id….
Oliver Terbu: This should not go in the evidence property. It is not the core we are trying to solve here.
… conf binding could support x509 identifiers.
… JoeAndrieu thanks for positive suggestions. I also prefer confirmationMethods.
Dave Longley: 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).
Kristina Yasuda: you still argue the best place to put this is the credSubject.
Oliver Terbu: yes.
Paul Bastian: First point is if the intention of VC spec to have a strong link to DID core spec..
… Seems weird to me. eidas uses the VCDM but never references DIDs.
… Dont need DIDs for keyConfirmation binding.
Dave Longley: 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..
Paul Bastian: We simplified problem. This just shows how someone can confirm that they are the subject of a credential.
Samuel Smith: 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..
Paul Bastian: Paper also proposes other places this property coould live. I prefer it to be under credSubject too.
… I don’t care too much about it.
… All credentials should be exportable, not the intention of this work. Check out the eidas ARM.
Dave Longley: “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).
Paul Bastian: To achieve regulated use cases you need to use hardware keys, these will be non exportable. That is unavoidable.
Kristina Yasuda: cnf claim that can be used instead of dids is defined in rfc 7800 https://www.rfc-editor.org/info/rfc7800.
Kristina Yasuda: also EUDIW ARF https://digital-strategy.ec.europa.eu/en/library/european-digital-identity-wallet-architecture-and-reference-framework.
Kristina Yasuda: also type2 in EUDIW ARF is only to illustrate the concept of “configurations”/”profiles” - EAA mandates type1.
Brian Campbell: RFC7800 defines the cnf claim.
Paul Bastian: This is not just another claim, because we want the syntax to be very clear about how to confirm the subject.
Orie Steele: In plain JWT world, if we do something other than cnf for this… we should expect some pain..
Paul Bastian: 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.
Manu Sporny: Feel like we are jumping all over the place. Can we pick and focus on one use case.
… Desire to solve this, but lack focus.
Samuel Smith: 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..
Manu Sporny: Lets take DID Auth and hard wallet binding off the table.
… E.g. okay I have a VC, it doesn;t have a DID in it. The uni used a passport to verify the subject.
Oliver Terbu: 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.
Paul Bastian: this example is in the paper.
Dave Longley: any use case where a person shares very little about themselves to get an entitlement may easily allow fraud via collusion.
Manu Sporny: Can we isolate this to one example.
Paul Bastian: I agree, the discussion on hardware-binding is separate.
Kristina Yasuda: don’t we want a mechanism that works for all use cases.
Manu Sporny: we do but lets focus on one to start with.
Kristina Yasuda: any use case to start with.
Orie Steele: need to understand other specifications that address this concern.
… Why are they not enough..
… should look at rfc7800.
… confimation claim isnt a subject it is a separate claim.
… terms of use is interesting. Is this something you dig in to do validation.
… is evidence a place I am going.
Paul Bastian: please don’t limit holder binding to keys! its better understandable if you think how to address both remote & on-site usecases with the same VC.
Dmitri Zagidulin:
@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.
Kristina Yasuda: 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.
Orie Steele: We should all read rfc7800.
Manu Sporny: 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?.
Orie Steele: Why are we reinventing that.
… cnf is a direct drop in for the binding property.
Michael Prorock: +1 orie.
Michael Prorock: https://www.rfc-editor.org/rfc/rfc7800.html.
Michael Prorock: and mixing that with claims.
Kristina Yasuda: i strongly disagree with cannot trust the issuer.
Dmitri Zagidulin: +1 kristina, that’s outside of the VC trust model.
Dave Longley: 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..
Paul Dietrich: On slide 29, mentioned about trusting the issuer. This is contextual to the claims.
… This is a claim about the subject, these can be ignored..
… Where does it sit. This is optional for issuer and verifier.
… I do see how this is needed.
Dave Longley: if you don’t trust them for anything in their credentials, then yeah, that’s out of scope.
Dmitri Zagidulin: responding to oliver comments that developers will be confused if they have to look in multiple places for claims.
… that ship has sailed in the VCDM already.
Kristina Yasuda: dlongley: yes, and i disagree verifier cannot trust the issuer for confirmation methods :).
Dmitri Zagidulin: developers always have to look in places other than the credentialSubject.
Dave Longley: 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.
Paul Bastian: thats not true, a VC can have multiple subjects, how do you know which is meant?.
Kristina Yasuda: dlongley: whether to use or not is absolutely up to the verifier.
Dave Longley: +1 (to kristina).
Samuel Smith: If going to have subject based verification method. And have VCs with multiple subhects. Makes this extremely different for verifier to interpret.
… If instead only allow one subject to have a confirmationMethod, this makes it simpler.
Orie Steele: 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..
Dmitri Zagidulin: 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..
Oliver Terbu: SamSmith I agree it can be confusing if multiple credSubject each have confimationMethods.
… dmitriz sure, but always better to make it as easy as possible for verifiers.
… Paul_Dietrich_GS1 if an issuer is not able to create this confirmationMethod then they don;t do it..
… if it is there then that is cause the issuer has enough certainty to make this statmeent.
… Orie I will look into rfc7800.
Kristina Yasuda: Don’t need to fit everything into this mechanism..
… see the usability of this mechanism on non crypgraphic mechanisms. E.g. biometrics like facId.
Brent Zundel: idea for a proposal - we add a confirmationMethod property that is extensible and point to rfc7800 as one normative way to do it.
Joe Andrieu: agree with concern SamSmith raised. But solution is already there..
… e.g. for a marrage certificate, there is multiple legitimate subjects of the VC. Each could be bound to a different subject.
… Limit the scope to one of the binding mechanisms. Focus on the scope of what we really mean.
Samuel Smith: q.
Joe Andrieu: Does it need to be automatable, are we talking about cryptographic.
David Chadwick: concerned that we might end up with duplicate.
… If we decide we want binding on PII e.g. name then we put it in the confirmation then these terms would be duplicated.
… don;t need confirmation method when it is obvious.
… need it when not obvious, e.g. x509 certificate.
… Might just be duplicating properties in credSubject.
Manu Sporny: We are talking about events.
… issuer did x to verify the credentialSubject on issuance.
… I am confused.
Oliver Terbu: We are not talking about the issuer did x to verify cred subject..
… issuer says you can use this mechanism to authenticate the subject of the credential.
… The confirmationMethod is a tool for the presentation process.
… provides inf to the verifier.
Manu Sporny: understood, but if the issuer hasn’t checked the things they put in the confirmationMethod then they shouldnt be putting this information in here.
Brian Campbell: lost some context, but want to add some clarity to Orie points.
… rfc7800 provides ways to represent a key with the intent that during presentation of that token proof of possession of that key is included.
… intentionally limited to single key.
… about the key with respect to presenting a token. Not necessarily about subject.
Paul Bastian: talking too much about different binding mechanisms..
… one of main idea of paper was to support different uses of VC. Remote, hybrid or offline and inpeprson.
… idea is we have a VC that can be used remote, online, automated or not..
… diff confirmation methods work for different scenarios.
… we have array of confirmation methods to support these different sccenarios.
… This is about providing a registry to name these types of confirmation.
Michael Prorock: regulatory environment will require this kind of thing.
… is there a way we can avoid registries of things.
… also does this exist elsewhere. If so lets point to those things.
Kristina Yasuda: lets take a break, are we ready for a concrete proposal.
Dmitri Zagidulin:
@brent- what if, instead, we propose to limit VCs to just one credentialSubject :) (could simplify the conversation greatly!).
(after break).
Dmitri Zagidulin: @JoeAndrieu - ha, I was gonna mention marriage license use case too. :) (in the argument that we can restrict VCs to a single credentialSubject).
3.1. Concrete Proposals for Holder binding.
Oliver Terbu: proposal is to focus on bikeshedding name, property location, property contents?.
… lets discuss this slide.
… should we use an extension registry for types for holder binding?.
Gabe Cohen: +1 to registry and extension mechanism.
… we should handle this like evidence / type.
… we should add MUST requirement for the issuer.
… subject evidence property proposal..
Orie Steele: believes we should separate the core data model aspects from mechanism and processing rules which should be handled in the securing specs.
David Chadwick: proposal we don’t need to cover claims in the subject use case..
… issuer should not use confirmation for subject claims..
… the use case we should cover, is when its hard to link the credential to the user..
… when its not obvious how to link confirmation to the user.
Dmitri Zagidulin: proposal 1: move confirmation method to terms of use, where it should contain an array of confirmation method types..
… proposal 2: we should restrict the core data model to only having 1 subject, just as we currently have only 1 issuer..
… we can cover all use cases without having multiple subjects, and multiple subjects does not play well with evidence and binding..
Samuel Smith: We should look at the use cases and threat analysis.
… we should not hand have around security guarantees regarding subject claims.
… we should do a threat analysis.
Andres Uribe: same.
Joe Andrieu: proposal is we should do marriage license use case, and do 2 scenarios, did auth and passport confirmation methods.
Dmitri Zagidulin: same.
Joe Andrieu: I don’t think we need registries.
… security is not about validation… this is business rules, not crypto..
… I agree with davidC, we should avoid duplicating if we can, but we may need to refer to things… do support confirmation methods.
… curious regarding dimitry’s single credential subject for marriage certificate..
Michael Prorock: officers of a company is another example.
Joe Andrieu: we are in <subject> <predicate> <object>, and we picked this path… based on discussions.
Oliver Terbu: I like the term “confirmationMethod” over “binding”.
Dave Longley: 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.
Dmitri Zagidulin: +1 dlongley, re nested entities.
Oliver Terbu: to orie’s point on layering… in general +1, but I want to define a framework… where each confirmation method has a type..
Michael Prorock: +1 to confirmationMethod.
Oliver Terbu: where each type defines what gets confirmed.
… what the issuer intended.
… we should define 1 or 2 types.
Dave Longley: it’s not clear what is being confirmed … what is being confirmed?.
Oliver Terbu: or we will encounter formal objections, similar to termsOfUse and Evidence..
… we should look at holder used MFA use case..
… maybe look at FIDO use case.
… i think confirmation is a claim on the credential Subject.
… I don’t think it belongs in termsOfUse.
… regarding samsmith, I think the use case document covers some threat analysis.
David Chadwick: 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?.
Paul Dietrich: +1.
Dave Longley: are you always confirming some level of identity assurance? … should these be identity assurance methods?.
Oliver Terbu: joe said he did not like regististries, but he does like types.
David Waite: 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.
… if a verifier ignores the issuer’s intent, the issuer is not liable for verifiers ignoring claims.
… its not clear if termsOfUse or claims is correct… there are no processing rules a verifier must follow.
Brent Zundel: seems like confirmationMethod seems to generally by well received term?.
Dmitri Zagidulin:
@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..
Orie Steele: (general agreement its better than binding in the room…).
Brent Zundel: what do we want this thing to do?.
… what is the one thing that we want to do.
David Chadwick: tell the verifier how to validate a subject.id that it is not obvious how to do this.
Samuel Smith: AssuranceMethod.
Manu Sporny: +1 to assurance method ^^^.
Joe Andrieu: +1 for assuranceMethod.
Dave Longley: assurance is better … but i think would be better with a modifier to go with “assurance”.
Paul Dietrich GS: +1 on confirmationMethod, name seems good…. the data structure, seems like it needs to relate to evidence, termsOfUse and credentialSubject claims.
… maybe its a seperate document.
Dmitri Zagidulin: @dlongley - like ‘identityAssurance’ ?.
Michael Prorock: +1 to different doc.
Manu Sporny: +1 to “modifier to go with assurance”.
Manu Sporny: authenticator assurance is also a thing :) per NIST.
Oliver Terbu: -1 different doc.
Dave Longley: I question confirmationMethod, because its only working in a narrow context.
… do you really need a confirmation method for: do you have a cat?.
Paul Dietrich: +1.
Dmitri Zagidulin: +1 dlongley.
Dave Longley: are these really just “identity assurance”.
Orie Steele: general agreement assurance seems good..
Oliver Terbu: +1.
Oliver Terbu: -1.
Michael Prorock: identity assurance seems good.
… is this just a list of things an issuer checked.
Will Abramson: DavidC mentioned that this is useful for when the subject identifier is not clear, I don’t love confirmation method.
Oliver Terbu: -1000 identity assurance.
Manu Sporny: I agree with Sam and Dave, we are talking about assurance.
… this seems related to identity assurace, authenticator assurance… that feels concrete.
Shigeya Suzuki: Subject identity assurance?.
Dave Longley: +1 to it being what the issuer checked … and the verifier could check it too if they want to..
Dmitri Zagidulin: we already have a place for ‘the issuer checked this’, which is the ‘evidence’ field.
Manu Sporny: we are talking about assurance, but what are we really saying, did the issuer check, or is the issuer asking the verifier to check.
David Chadwick: there is a CCG draft for evidence property use case and KYC.
… OIDF is looking at how to use evidence for this use case.
… lots of work happening in OIDF on evidence, we should use what OIDF is doing for assurance.
… I think this is not about assurance, its about the identifier, not the identity attributes.
… this identfier should be checked on presentations….
Joe Andrieu: We need to distinguish, how should a verifier process a presentation.
… I would not call that identity assurance.
… I would say it is assurance though.
… we are not trying to track a physical body.
… we are trying to correlate activities.
… we are not confirming DNA / presence, etc….
… I do think it needs to be open ended.
… people don’t have identifiers.
Brent Zundel: +1 to Joe.
Michael Prorock: subjectAuthMethods.
Orie Steele: time boxing intensifies.
Oliver Terbu: I agree.
… mumbles about sleep….
Michael Prorock: i resemble that remark.
Oliver Terbu: this is about the process of … assurance, but not identity assurance.
… NIST has stuff on this, IAL, AAL, FAL… but that seems not what the verifier does, its what the issuer does.
… when I speak of assurance, I think about the full lifecycle.
… proof of possession for holders, MFA, etc… Identity Assurance boxes us in… i don’t like that.
… EIDAS does not distinguish between all of these, but they do have levels.
Dmitri Zagidulin: and by ‘holders’ we mean ‘presenters’, right?.
Oliver Terbu: they have lots of stuff that we don’t want put in the credential.
… I like abstraction that saves us from embedding all that.
Samuel Smith: do we need to do both? id assurance by issuer vs id assurance by the verifier?.
… we should cover both cases in this method.
… there are liability concerns that vary.
Brent Zundel: evidence is for what did the issuer do.
Joe Andrieu: +1 to cover both issuer evidence & verifier guidance with similar means.
Samuel Smith: verifiers need to know what issuer intended, and how to comply to benefit from liability coverage.
… internals might not need to be communicated to verifier.
Brian Campbell: +1 to Oliver that identity assurance is not an appropriate term.
Orie Steele: 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…
… On the issuer appraisal side of this, evidence is wha we should use/remove..
Drummond Reed: I agree with Oliver that the property should NOT be called “identity assurance” because that’s not what NIST means by that term..
Michael Prorock: it doesn’t help that evidence isn’t really defined - is evidence identity related or claims related or and either/or situtation.
Drummond Reed: IMHO the best term is “vc-to-subject-binding”..
Orie Steele: 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..
… 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..
Dave Longley: 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.
Joe Andrieu: Should we use the same mechanism for Evidence for this?.
Michael Prorock: assuranceMethods vs identityAssurance.
Joe Andrieu: evidence they used to establish global entry is different than what verifier might use to process claims.
… different jursidications might have different requiremetns.
… the verifier might not be able to use all confirmation methods proposed by the issuer.
Oliver Terbu: +1 joe.
Manu Sporny: Feels like evidence is easy to use.
Dmitri Zagidulin: +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..
Manu Sporny: I am concerned about adding constraints for the verifier, and presumption of liability transfer.
… that seems to raise the specter of lawyers.
… concerned about the second part of this, and communicating the requirements to verifiers.
… seems like issuers might get that wrong.
Joe Andrieu: +1 to avoid “liability” in our languaging.
Manu Sporny: seems there is danger, expressing “non liability”.
… can we tackle the evidence use case first?.
Michael Prorock: clarifying this is related to the credential subject.
… but I keep hearing this is about what a verifier MAY do.
… what methods might a verifier use to verifify the subject is authentic?.
… maybe its not ID assurance….
Samuel Smith: 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.
Michael Prorock: we should cover the notion of levels / priorities for confirmation methods.
… seems like we are hearing requirments regarding levels.
… are these real requirements, or are they in conflict?.
Dave Longley: 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”.
Michael Prorock: we should list confirmation methods and protocols needed.
Brent Zundel: We should communicate the options to the verifier.
… maybe you want to use holder binding?.
… are we ready for a PR.
Michael Prorock: must the issuer check this stuff before including it?.
Joe Andrieu: I think we are ready for PR.
… go do a PR oliver.
… on the notion of evidence, we can’t use the current top level property for this… because we use evidence for different things today..
… we need evidence for claims?.
… it needs to be tied to claims, not to the vc.
… lets put stuff in the credential subjet.
Dave Longley: or perhaps the language should be “the presenter can prove control over the identifier used for a subject in the VC”.
Samuel Smith: +1 to evidence on a subject basis.
Samuel Smith: +1 to adding evidence at the subject level.
… ecosystem governance is where the legal issues will get solved.
… it will business, industry, regulatory… we don’t need to add that to the VC itself.
… if we don’t all people to use practical legal frameworks, we won’t get to practical use cases.
… and real world use case, won’t work, because law is more complicated.
Oliver Terbu: I agree.
… yes..
… the current evidence property might need work.
… I will try to make a PR.
… in the VCDM.
… I will propose a framework.
… after there is small agreement, I will try for an example.
… we also need to update the use case document.
… I am happy.
… I know what I need to do.
Joe Andrieu: I will split the difference on agreement with Manu.
… we need to be careful about stating re liability.
… we should be clear regarding liability.
Michael Prorock: +1 JoeAndrieu - this is about methods.
Samuel Smith: We should have a PR, that includes separating crypto assurance from data model payload / claims.
4. Extension Points.
Brent Zundel: look at these things that need to be fixed.
… we need to fix dereferencing.
… first question, where are these terms defined.
… second question, look at these extension points.
… all these are non normative.
… and we don’t even point to a single way to use them.
Paul Dietrich: URL?? Did this change in 2.0? In 1.1 I though they were URI?.
Brent Zundel: we need to point to something.
Dave Longley: Paul_Dietrich_GS1: URL is the same thing as URI in the new world..
Brent Zundel: the reason for this, is because… we have been dinged on our charter for this stuff.
… its considered to be not a good thing, what we have done..
… we feel we can do better.
… what should we do about these things?.
… should we remove these things… since we have nothing to point to.
Kristina Yasuda: for refresh: issues 981, 1020.
Kristina Yasuda: for terms of use: issue 1010.
Orie Steele: 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.
Kristina Yasuda: issue 991 says it is about status, but not really…
Kaliya Young: +1 orie!.
Orie Steele: removing them from the doc does not mean they aren’t useful or fine, just that they don’t belong in the spec.
… let’s avoid FOs, let’s do a better job.
… let’s get things polished, then add.
Dmitri Zagidulin:
@Orie- do you think we can thread the needle by just having a list of ‘reserved terms’ in the main VC WG spec?.
Manu Sporny: there is also a render extension.
… we have one for status.
… we could point to the CCG for some of these.
… for refresh for example.
… as far as dereferencing, it depends on the type.
Dmitri Zagidulin: as in, would ‘reserved terms’ without definition raise objections?.
Manu Sporny: in many cases, its just a URL.
… sometimes its a URL to another file type.
… not sure what we can do, to fix this.
… they can be ANY url.
Brent Zundel: Can we say more than, it is just a URL.
… we need to define it a bit more.
Manu Sporny: what about a human readable web page?.
Brent Zundel: we need at least 1 way to do things.
… we don’t need more than 1.
… people need to be able to read the spec to understand how to use these extension points.
Dave Longley: we should also say, these id’s depending on where they occur, they don’t need to derefernence to things.
… we should explain when urn:uuid is more appropriate.
Michael Prorock: +1 uuid - that is often a desired behavior.
Dave Longley: we should describe what a holder dererefernces too, it should go to a controller document, like issuer.
Dave Longley:
"id": "urn:uuid:<uuid>.
Michael Prorock: +1 to uuid, maybe we cover URN in URL examples as well.
… sometimes we like to define schemas in vocabularies.
… sometimes we over URLs, hashes, etc….
… no blockchain required.
… md5 is till observed in the wild… maybe hashes should be documented?.
Dave Longley:
digestMultibase:).
Michael Prorock: should be integrity protect schemas, how?.
Dmitri Zagidulin: +1 to using digestMultibase (which includes hash and content type).
Michael Prorock: we should describe what we are seeing in the wild.
Gabe Cohen: we have one in the CCG.
… there is one in the CCG, I would like to move it into this working group, similar to status list.
… so it can stay in the spec.
Joe Andrieu: I am in favor of removing things that are not defined….
… we can use CCG for optional fields.
… we need to remove SHOULD from some of these.
Samuel Smith: 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..
Joe Andrieu: URLs being here is because of WHATWG… confusion.
… maybe we need to change the guidance on this.
Kristina Yasuda: the property part… status we have a work item.
… credential schema, at risk..
… refresh service, I am against including it.
… termsOfUse, no strong opinions, it seems at risk.
… evidence, lots of issues, ccg item exists, but regarding brents original point, we can’t spend time on all of this.
… render, seems useful, but maybe we don’t need it just yet.
… render seems at risk.
… chair hat off for comments.
David Chadwick: Not sure we need to point to standards.
… we don’t have any standard terms of use, but we are pointing it at trust infrastructure.
… its using EIDAS trust lists.
Samuel Smith: 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..
David Chadwick: does it have to be a standard? seems like the bar is too high.
Dmitri Zagidulin: concrete proposal, we remove these sections from the spec, but then reserve the terms.
… so that we can have seperate specs for each one.
Brent Zundel: our charter does say, for all normative required properties….
David Chadwick:
@dmitrizvery interesting comment!.
Brent Zundel: we acknowledged there is a problem here, but it does not mean that we should aim for the low bar we set..
Dmitri Zagidulin: @dlongley - what if we phrase it ‘Reserved for future use’? :).
Brent Zundel: lets consider why we are keeping things we can’t provide references for.
… agree with dimitry.
Dave Longley: dmitriz: i’d be worried that DavidC’s usage would be invalidated by that language.
Dmitri Zagidulin:
@dlongley- remind, what usage is that?.
Orie Steele: notes variations on VC JSON Schema and other ways of linking json schema to credentials and formats.
Dave Longley: dmitriz: he just mentioned he’s using termsOfUse with EIDAS.
Orie Steele: maybe we don’t have to point this to a normative standard.
… however at ietf dowrefs are disouraged.
… for good reason to that people are only being directed to stuff that is “real”.
Ted Thibodeau Jr.: W3C allows pointers to specs-in-progress, there just has to be a static, permanent document.
Dmitri Zagidulin: @dlongley - he’s ‘future use’! :).
Orie Steele: 100% agreement to remove all this stuff.
Ted Thibodeau Jr.: those pointers can’t be normative, however.
Orie Steele: +1 dimitriz.
Brent Zundel: I understand we have the same notion regardingn Downref.
Michael Jones: its a bit of a tangent, on WHATWG.
… the names are meaningful, and we should maybe not have… since its not great.
Phillip Long: +1 dmitriz practical suggestion re: reserved usage.
Joe Andrieu: I am a big fan of removing first, and adding good stuff that meets our bar back.
Dave Longley: +1 to Joe, reserving the terms eliminates the ability to experiment.
Joe Andrieu: I am opposed to “reserved terms”, because it would prevent people from experimenting.
Brent Zundel: so far quite a few folks in favor of removing terms.
Michael Prorock: thank you joe for the reserved comment.
Joe Andrieu: the question I have is regarding termsOfService.
… is that VC and VP?.
Dmitri Zagidulin: if ‘termsOfService’ is only in VCs, Phil and I will be adding a proposal to adding ‘termsOfUse’ to VPs.
Joe Andrieu: doc searl is working on something related to that… maybe its an option.
Manu Sporny: the objectors, we spoke to them… they wanted proof there is interop on these things.
… that is a much lower bar than REC or defintion.
Joe Andrieu: doc searls’ work is over at https://sagroups.ieee.org/7012/.
Manu Sporny: we can just point to CCG things.
Joe Andrieu: (user generated terms of service).
Manu Sporny: I think I am -1 to removing things pre-maturely.
… some things seems safe to remove, other seem like we should not remove.
… credential refresh is deployed, we don’t want to remove that….
Kristina Yasuda: it’s in v1.1.
Manu Sporny: we would just violate the spec, if we remove things we use in production.
Kristina Yasuda: nooooooo.
render is not simple at all.
we have a variation of “render” deployed too.
Manu Sporny: render is simple enough… we should be able to do that in CR.
… lets talk about it, maybe this will work..
Kristina Yasuda: but it is not simple and it is not only about svg as in PR.
Dmitri Zagidulin:
@kristina- render /is/ simple as an extension point..
Manu Sporny: 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.
Kristina Yasuda: for render, at least just point to a spec in DIF, no reinventig please.
Manu Sporny: is anyone using termsOfUse?.
David Chadwick: We used it in tests.
… it communicates trust framework.
… if you demonstrated interop, then it stays.
Dmitri Zagidulin: @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).
Kristina Yasuda: refresh has been causing a lot of confusion.
Brent Zundel: If there is something on this list, that you are using, will you raise a PR to modify the spec to point to something?.
Ted Thibodeau Jr.: link to “this list”?.
Oliver Terbu: there is a number of ppl that use credentialSchema with JSON schemas.
Brent Zundel: slide 72.
Ted Thibodeau Jr.: tnx.
Dmitri Zagidulin: +1 oliver – Open Badges v3 uses credentialSchema w/ json schema.
Brent Zundel: we need to concretly move forward.
… seems people want to do things, but will they open PRs?.
Kristina Yasuda: 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.
Michael Prorock: The danger of reserved, sounds great, but … maybe its not a good solution.
Phillip Long: +1 Oliver, so does CLRv2 from 1EdTech and they have for both OBv3 and CLRv2 at least four commercial vendors committed to implement it..
Michael Prorock: it seems reasonable to clarify language on URLs.
… I will maybe open a PR.
… implied by the core of what we do is status, the other items, maybe we should drop the rest.
… they can be used.
… they don’t need to be pointed to CCG docs.
… CCG is awesome place to incubate, but it doesn’t seem like a good place to point to… for the single reference for TRs.
… anywhere we are considering to pointing to the CCG, seems dangerous to the work….
… we can recharter to cover items, lets not use the CCG to cover overflow.
David Chadwick: I covered termOfUse.
Paul Dietrich: was there any conclusion on dereference URLs vs non dereference?.
Dave Longley: -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..
Dave Longley: we have enough other real issues to address..
Brent Zundel: We seem to want to clarify URL vs URN as legal for use cases.
Dmitri Zagidulin: 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..
Michael Prorock: we can cover cases for both URL and URN, DID etc….
… we can provide better language.
See github issue vc-data-model#914.
Andres Uribe: @dmitriz I believe that’s already defined in https://www.w3.org/TR/vc-data-model/#extensibility.
Joe Andrieu: We should back away from WHATWG.
… it breaks file URLs.
Dmitri Zagidulin:
@andres- oh right!.
Joe Andrieu: so seems like we should not follow that guidance.
Kristina Yasuda: also a bit related: https://github.com/w3c/vc-data-model/issues/709.
Joe Andrieu: question for Manu, no snark implied.
Kristina Yasuda: and this kind of https://github.com/w3c/vc-data-model/issues/945.
Joe Andrieu: my understanding is that your current VCs won’t break anything, because you already cover this use case under 1.1.
Dave Longley: https://url.spec.whatwg.org/#example-url-parsing <– some examples of valid file URLs are in there.
Manu Sporny: Do we want to open that can of worms.
… it is true that 1.1 context, will perserve terms that are dropped.
… some folks won’t be insulated from breaking changes.
Dave Longley: -1 that v1.1 will be affected, the JSON schema would still check the literal context values.
Manu Sporny: why are we trying to do work that was not asked for by objectors.
Joe Andrieu: because it’s not about formal objections.
Gabe Cohen: PR to add a schema reference https://github.com/w3c/vc-data-model/pull/1042.
Manu Sporny: the reason we added extension points, was to allow people to use them.
Michael Prorock: we don’t have requirements for this.
David Chadwick: +1.
Manu Sporny: we don’t need to describe anything, just let people use the extension points.
Dave Longley: +1 to Manu … stop messing with people that are doing useful things :).
David Chadwick: we are actively using ToU.
Manu Sporny: concern is that we are solving a non problem.
Orie Steele: Lets try to raise some PRs.