F2F mapping converstation

The issue was discussed in a meeting on 2022-09-15

no resolutions were taken

View the transcript

### 2. VC-JWT. > *Ivan Herman:* Slides start at [https://docs.google.com/presentation/d/128DHWSzVxPgAhB0mq-h23_iATnbVeA4Y-JhNLjpcXJE/edit#slide=id.g1f071ce6e7e_3_18](https://docs.google.com/presentation/d/128DHWSzVxPgAhB0mq-h23_iATnbVeA4Y-JhNLjpcXJE/edit#slide=id.g1f071ce6e7e_3_18). **Orie Steele:** presentation about VC JWT, PRs, and take temperature of SD-JWT. … review of registered claim names. Make better use of registered claim names. Examples shown on slide.. … public claim names. Collision resistant names are important.. … private Claim names. Not registered. Imaging all kinds of other names to include in token that you dont care to go to a registry.. … We can agree to interpret these claim names consistently. They are subject to collusion and used with caution. … organization_id may be an example of both good and bad. **Michael Prorock:** Note these important things. Tend to see this between parties trying something out. Also see in developer docs that publish private claims with rules.. … Expect that we see similar things with VC-JWT. Developer docs with private claims.. … The other callout from previous slide. This isn't unique to private claims, JSON-LD addresses with vocabs, but there are other mechanisms. **Orie Steele:** Example from slide 91 PR #44. … Walking through example with differences between ld+json and +jwt. _See github pull request [vc-jwt#50](https://github.com/w3c/vc-jwt/pull/50)._ _See github issue [vc-jwt#53](https://github.com/w3c/vc-jwt/issues/53)._ **Orie Steele:** You can have properties in JSON. Everyone expects that they can be ignored if you don't understand them.. … the JSON `@context` member is allowed and not required. **Manu Sporny:** I missed this when reviewing PR 33. All of a sudden we made `@context` optional. Secondly, its not a verifiable credential or credential. Its arbitrary JSON (a JWT claim set).. … I think its highly problematic. Missed during a review.. > *Ted Thibodeau Jr.:* +1 manu. > *Dave Longley:* +1 manu. **Manu Sporny:** massive -1. Believes this is the wrong thing to do.. **Orie Steele:** Would you prefer we call them credentials. > *Paul Dietrich:* manu-: I prefer we call them JWTs. **Joe Andrieu:** We don't have an unsecured media type for a credential claim set.. **Orie Steele:** the cty property that has been adopted has a -1.1. The one shown here doesn't have this.. **Joe Andrieu:** I don't understand why we are talking about a credential claim set that are not a VC. … This feels out of scope. It feels like a different thing being secured.. **Orie Steele:** are you talking bout credential-claim-set versus credential+ld+json?. **Joe Andrieu:** definition of what a VC is is not what is at point. VC data model defines a VC but that is not this (slide).. **Orie Steele:** There is two parts of the spec to review together. First is the definition. Second is every normative statement that is a requirement. Those are what a VC is.. **Joe Andrieu:** Do you believe the stuff on the right meet those requirements?. **Orie Steele:** Lets start with the definition. **Ivan Herman:** say the say thing as Joe. The right hand side is not what we defined in the VC data model, except for the context which is optional.. … This is ok, but not what this working group is working on. I don't see how this comes into the picture.. **Dave Longley:** Agree with manu, Joe and ivan on this. Getty very confused on the processing rules to understand this. Would have to go back to some mapping rules which I though we were moving away from. > *Phillip Long:* +1 with Ivan, Joe and Manu - this is out of scope.. **Dave Longley:** looks complicated and out of scope for the group. **Michael Jones:** this came out of a desire to have VC-JWT to be simpler than in 1.1. … There have been mappings that keep the VC identifier and the JWT identifier. This can been a complexity nightmare for implementors.. > *Michael Prorock:* [https://w3c.github.io/vc-jwt/#relation-to-the-verifiable-credentials-data-model](https://w3c.github.io/vc-jwt/#relation-to-the-verifiable-credentials-data-model). **Michael Jones:** It was the view of the editors to have no mapping rules. So we created for v2 a native JWT representation of VC. No question that they are credentials and verifiable. They don't use all the claims from the VC data mode.. > *Dave Longley:* i'm +1 for recommending against using the "instead of" mapping and using encapsulation or just having the content be a credential directly, those are both reasonably clean, IMO. **Michael Jones:** this makes it simpler than 1.1. It admits the mapping was a mistake and that we should use native claims directly. **Michael Prorock:** a couple ways this discussion can go. Initially read the definition. Pasted into the minutes.. > *Michael Prorock:* [https://w3c.github.io/vc-data-model/#terminology:](https://w3c.github.io/vc-data-model/#terminology:). > *:* credential: 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.. **Michael Prorock:** Read from section 1.1 in VC-JWT. Relation to the VC data model. Defines encoding rules to covert. Defines how to make use of VC-JWT specific claim names.. … I think that if we already have registered claims in JWT (mapping) lets use them.. … however, suspect that there are things in the VC data model, where it says it MUST have something that do not have registered claim names.. > *Dave Longley:* a simplistic summary of what a verifiable credential is not a normative definition of the actual, interoperable data model. **Michael Prorock:** There are stuff not covered by registered claim names. These are the things that make VCs VCs.. … question for group. What example would make this a VC? Duplicate values? Context? Can we get this info.. **Manu Sporny:** Normative language in the spec and these are not in the VC-JWT example.. > *Phillip Long:* very persuasive. > *Michael Prorock:* [https://w3c.github.io/vc-data-model/#conformance](https://w3c.github.io/vc-data-model/#conformance). **Manu Sporny:** We have a conformance specification and states clearly what forms a conformant document.. > *Joe Andrieu:* from the spec: A conforming document is any concrete expression of the data model that complies with the normative statements in this specification. Specifically, all relevant normative statements in Sections 4. Basic Concepts, 5. Advanced Concepts, and 6. Syntaxes of this document MUST be enforced.. **Manu Sporny:** The thing on the right is not any of these things.. … The thing on the right is a JWT claim set and not what this group does. Feels like describing a JWT and trying to call it a VC.. … What is the use case here? Totally agree that mapping was a bad idea.. > *Dave Longley:* +1 mapping was bad :). **Manu Sporny:** not in our charter to do this. unless we want to come up with mappings again.. > *Michael Jones:* From the 1.1 spec: "Verifiable credentials represent statements made by an issuer in a tamper-evident and privacy-respecting manner.". > *Michael Jones:* And "Credentials represent statements made by an issuer.". **Gabe Cohen:** What will it take to make more sections normative to prevent lawyering.. … Agrees this is not a VC as described today.. … necessary to have a native JWT implementation of VC.. … There is a conception of a VC that encapsulates a JWT that is not just a JWT. **Andres Uribe:** My interpretation. Normative pieces are: must be a context. must have a credential subject. When manu referred to mappings is this what you mean?. **Manu Sporny:** yes. **Andres Uribe:** If we step away from JSON and support protos. What does that mean for names? (protobufs). > *Dave Longley:* choosing a number of statements that are intended to help the reader understand at a less-technical level what something is in a specification (*any* spec) ... does not change the rest of the spec or what normative parts are needed for interop and conformance. **Orie Steele:** VC-JWT today describes the mapping from vc-credential+ld+json to a JWT. These rules say that properties can be omitted that are required in the core data model. > *Michael Prorock:* big +1 to what orie is saying here. **Orie Steele:** implemented 1.1 VC-JWT and 1.1 data integrity. mapping problem in 1.1 was a real problem.. > *Dave Longley:* +1 ... the VC-JWT 1.1 mapping "optionality" was a good example of not "just making a choice in a standards group" when two things do the same thing... and clearly "in addition to" was better and should have been chosen.. **Orie Steele:** in 2.0 we described 1.1 better. We also gave unique names to the content. We should make arguments clear as this is the beginning of a rational debate.. … Is this a zero sum game for branding of what a VC is. If core data model says it must be JSON, then it prevents alot of futures people want to get to.. > *Dave Longley:* -1 to shutting the door vs. saying v2 only does X.. > *Michael Prorock:* even bigger +1 to what orie is saying here. **Orie Steele:** Concerned that it may be pigeonholed into a dead end if we can talk about binary .... … concurred there are numerous problems in the 1.1 vc-jwt. they cannot implement it. additional information needs to be contained to have interoperability that is not in the specific.. > *Michael Prorock:* e.g. of what orie is saying - that difficulty in implementation is part of what lead to jws2020. **Orie Steele:** intention is to clearly communicate what working group members want.. … better to describe what people are doing rather than tell them to use long names when its their best practice to use short names.. > *Dave Longley:* sometimes there will be conflicts with technologies and choices have to be made.. **Michael Jones:** agree with co-editor (Orie).. … VC 1.1 spec has a representation as a JWT.. … Have an opportunity to embrace other representation of credentials that will come out whether or not we do it here.. … Already have experience that mapping creates more problems than it solves.. … much like we worked on a native JWT implementation of a credential, we might need to develop a CBOR representation.. … Hope this parallels the JWT representation.. … reading from 1.1 spec .... … reading definitions of credentials and verifiable credentials. … takes objection to the statement that they are not verifiable credentials. Take objection to the statement that this is not what the group does. Please accept that these are VCs made by this work group.. **Michael Prorock:** Note that this is still a draft. Merging 44 doesn't mean the workgroup has done this.. … this is not a VC because its not encoded as a JWT with a signature. we would need to see that.. … What is the bare minimum of a VC and compare with this. There are gaps with what are presented on the right hand side between it and a VC.. … But if there is a registered claim mapped to the same meaning, why would we duplicate that.. … I want to be able to use this with bigger data and consistently and right now that is difficult.. … side with Manu that we should mandate the inclusion of a context.. … semantics are important when processing this data as an interconnected graph. **Manu Sporny:** We have mentioned binary expression of VC multiple times. This exists today as CBOR-LD and it is deployed and working. These arguments about binary are not convincing at all. That mechanism does do mapping leveraging the context.. … we took this approach because of the open world model and can't expect that every term is managed by a working group.. … they do automated mapping from the data model to an arbitrary middle format. When you verify you back into JSON just like the data model.. … much less problem if that was the approach we are taking here, but we are not.. … We are saying that manual mapping was a bad idea and we should never do it again. Automated mapping has worked well.. > *Andres Uribe:* whats the difference between manual mapping and automated mapping?. > *Dmitri Zagidulin:* I think the distinction between 'manual mapping' and 'automated mapping' is kind of murky... **Manu Sporny:** if we have a different context for a JWT you could keep the JWT names and there would be an automated mapping because of the context the JWT people can ignore that would reconcile this method.. … There would have to be some automated mapping of some kind. But this proposal feels dead in the water to me.. … demonstrated that we can get to binary already. > *Ted Thibodeau Jr.:* +1 manu, throughout. **Manu Sporny:** normative statements in the document are not satisfied. Just because we merged doesn't mean we agreed.. > *Michael Prorock:* so is it the LD part that is the issue (or lack of it in the example)?. **Joe Andrieu:** I don't think this was merged with consensus.. … as Manu said we do have CBOR LD. Pure FUD if we say we can't get to CBOR. We can get there.. … This is not a W3C VC. In the W3C VC working group, they mean W3C VCs, which it is not. Does not meet the normative requirements in the VCDM.. … as we have said before, our job is to make choices. Having two fundamentally different data models is not effective.. … We must agree on the single model of the thing that we are securing with our different data integrity methods.. > *Ivan Herman:* +1 to JoeAndrieu. **Dave Longley:** Agree with Joe. I dont think that this limits us to add more in version 3.. … we could pick any spec and ignore normative statements and say it meets the spec.. … For example we could grab the opening statement from the JWT spec interpret this. … The VC-JWT 1.1 rules met the requirements of the VCDM.. … Sometime when you coming two technologies to get their benefits, there will be conflicts and you have to chose between them. That's oK and part of the standards process. > *Dmitri Zagidulin:* can you hear me ok?. > *Dmitri Zagidulin:* one second. > *Manu Sporny:* /me no audio. **Dmitri Zagidulin:** discuss mprorocks early question. What would the right side have to look like. … It would have to have the required VC fields. issuer and credential subject. … the claims about the subject and VC must be separated on different nesting levels. Right side would have to maintain this.. … name in this example is the name of the VC not the name of the subject. … given that our goal is compactness, there are ways of making context required and keeping it compact, like CBOR-LD.. … summary: Not all the required fields, and makes context optional.. … iss is a string only. but VCDM is an object.. > *Dave Longley:* another important requirement: "Libraries or processors that support JSON-LD can process the `@context` property using full JSON-LD processing as expected.". > *Ted Thibodeau Jr.:* resuming ~1pm ET. > *Ted Thibodeau Jr.:* +1 dmitriz, dlongley. **Orie Steele:** we've been talking about data integrity and JWT as the only ways to secure the core data model - in 1.1 there was this other thing we talked about - CL signatures and other things. That existed back then, there was similar questions about whether it was or not a Verifiable Credential. Historical context, not new that we've had trouble determining whether something is a verifiable credential.. … CBOR-LD is not a verifiable credential but a transformation on verifiable credentials, similar to GZIP. Talked a bit over lunch, hidden in that is some important next-step types of things. A mapping to and from a VC is different from a native format.. … the other thing we discussed over lunch, there seems to be some amount of consensus that mappings were important for understanding whether you are talking about a verifiable credential. There is trivial mapping, such as credential+ld+json - these bytes are a credential. That trivial mapping seems to have some type of agreement.. … if mapping is fundamental to what a credential is, how can we constrain that (mapping) to get further agreement. If I have opaque blocks that I feed into a black box, if I get out something that looks like credential+ld+json, that may be acceptable. How much of that black box needs to be exposed, and what does this opaque format look like -w hat sort of constraints do you have.. … sidesteps the native conversation somewhat. > *Dave Longley:* +1 to the fuzzy idea of something that goes into / comes out of a black box as a credential+ld+json (and securing that content) being a verifiable credential. **David Waite:** Just wanted to clarify something... MikeP said `@context` is one of the required fields, mapping layer from JSON to RDF, if issuer isn't there, it will just map to something that isn't an issuer. It's the specification that creates those additional requirements.. > *Dmitri Zagidulin:* (also has to be an object, in addition to url). **David Waite:** one of the requirments we could have is it has to be a URL with same semantics... difference between binary and native formats... when you talk about CBOR as a compression algorithm in a QR Code, if you talk about IOT devices as json or RDF processing model, but they need to include URDNA, it becomes a bit untenable, wont work for some deployments, not enough physical size.. **Michael Prorock:** lead to possible proposal - if we can reliable go from one format into a VC-compliant document, thats ok then to say "this is a VC". Some of this has been presented before - but we could define a vocabulary that takes in VC data model and then defines the terms that have a direct correspondence in a JWT, and uses them as defined by the context in verifiable credentials - must downselect certain capabilities. … if that is a viable path, the other implied option is to say since we are already down selecting and since this is version 2, we could state that it must not contain a context in the vc-jwt itself - but if you are going to call it a vc-jwt, this is the context that is to be used in that conversion such that you get a compliant vc data model document. > *Brian Campbell:* like an implied context.... **Michael Prorock:** the advantage is that we can have things which just look like a normal JWT - possibly with additional required properties, that can always go back to VC data model. It also sets up from a CBOR standpoint to use those existing mappings for already defined claims, and use those existing encodings. > *Dave Longley:* would have to see the details of what Mike Prorock is saying, but the general theory seems like there may be a way to have that work, at least for some use cases. **Michael Prorock:** implicit XSLT, but dislike it compared to other options such as not having semantics about things in core VC.. > *Dave Longley:* +1 to ... any credential+ld+json => magic transformation => JWT => magic untransformation => same credential+ld+json. **Michael Jones:** I apreciate efforst to engineer a path forward, helpful to have face-to-face meetings to incubate such ideas. Could live with that mapping - that cynical Mike could then say you could define a mapping that concrete implementations choose not to use (to VC data model).. **David Chadwick:** party A has a document in the VC Data Model, has the subject and optional attributes - they put a proof on it - JSON-LD, JWT proof. Pass it to party B, strips off that proof, passes it back to A. They will end up with the same document they started with *nods*. … the issuance time, are not in the data model. The crypto can a different lifetime (in JWT) than the credential claims themselves - a driving privilege may be good for decades, while several licenses may need to be renewed over the years. The id of the credential becomes the issuer, then the VC property contains the VCDM.. > *Dmitri Zagidulin:* (the only thing that gets lost in most automated mappings, is the timezone on the 3 timestamps). > *Michael Prorock:* that is 1.1 approach. > *Dmitri Zagidulin:* since JWT expresses timestamps as epoch seconds. and timezone is lost. > *Michael Prorock:* +1 dimitriz - the spec needs text around these items, e.g. zulu time. > *Kaliya Young:* he said NGI-Atlantic before mentioning JFF. **David Chadwick:** We have shown this between issuers and verifiers JFF plugfest - ran through schema rules and conformed to VCDM. Put the entire VCDM and put it into the VC claim. > *Dave Longley:* DavidC's approach sounds viable. > *Dmitri Zagidulin:* `@dlongley` - wait, DavidC's approach is the 1.1 approach, no?. > *Dave Longley:* dmitriz: it's a tweak on it. > *Dmitri Zagidulin:* what's the tweak?. > *Dave Longley:* dmitriz: get rid of "instead of" is the biggest most important tweak. **Manu Sporny:** +1 , value in certain kinds of mapping. Previous mapping did not work out well. Two proposals - David Chadwick's approach is to copy without omitting, Mike Prorock's suggestion is to define a mapping for fields to and from claims set. Concerned that translations have problems, such as dates and issuer strings. You would end up with something that looks more like a JWT. Feel David Chadwick's approach is cleaner due to separations. **Samuel Smith:** make a modified proposal - like the idea of implied `@context`, it allows for a broader adoptability of VCs - if for not other reason that if you made a graph; one axis people who benefit from primary intent of linked data, with end-to-end semantic interoperability. … secured with data integrity or other proof. But for many implementations that provides little benefit with a lot of cost. … on other axis, we have security - applications that find linked data proofs sufficient and appropriate for their needs, other find they do not benefit from a linked data representation (and need another form of security) or the data integrity proof is insufficient for their needs. … so you now have four quadrants, but only one is satisfied when RDF is a representation. We can argue whether they are important, and if so that is the will of the working group. If we agree those others need to exist, then the implied `@context` helps us get there.. > *Dave Longley:* sound like a given "intermediate securing format" can do whatever it wants ... as long as when credential+ld+json (which always has `@context`) gets transformed ... it's lossless; you always get it back again as the same credential+ld+json.. > *Dmitri Zagidulin:* +1 to Joe's point, I think Sam's current point is off topic. **Samuel Smith:** you would not get the benefit of the intermediate representation. Been arguing we should have a layered approach, the cryptographic operations are distinct from the usability of the claim set. NIST does a good job where they separate IAL and AAL (assurance levels). When we talked yesterday about the issuer binding etc assurances, we are using that NIST model where you have assurance levels. What we didn't say is what authenticator assurance[CUT]. … but those don't belong in a claim set, they have to do with the authenticator. They may have something to do with the subject - and can be linked by the same identifier. By conflating the two, we create confusion. By making that distinction, we make it clearer for others to consume what we are defining.. … that means authenticators are metadata, and are not in the claim set or intermediate representation. **David Chadwick:** point out that mike's proposal is flawed from a security perspective - the issuance and expiry of the credential are not the same of the credential are the same as the JWT. The previous example of the driving license. If you do mappings between them, you will get in trouble.. > *Michael Prorock:* provide a vocabulary and set of rules (e.g. around epoch time) that describes registered claims in JWTs in json-ld, and add other definitions as required that must be present in the JWT - this context must be used to translate from a JWT to a valid VC. **Michael Prorock:** doesn't disagree with David - there are mappings between some of the registered claims, and how you can do those with a JWT - it is not 1:1. There is this notion that certain other data fields would be necessary there. This gives us the opportunity to identify those, possibly add new claims if needed. Provides us a way to reconcile these two things.. > *Kristina Yasuda:* > this context must be used to translate from a JWT to a valid VC. > *Kristina Yasuda:* mprorock, so now everyone who uses vc-jwt needs to do the transformation using context..?. > *Orie Steele:* I filed [https://github.com/w3c/vc-jwt/issues/53](https://github.com/w3c/vc-jwt/issues/53) to cover the 3 kinds of mapping I heard.. **Joe Andrieu:** defer some comments on optional `@context`. Highlight something DavidC touched on - which is the conflation of real world credential lifetime and the VC lifetime. In my case I would argue that his example is incorrect - the lifetime on my physical driving license is that of the physical credential and not the driving privilege on at a DMV. A bunch of the JFF folks. … used the ID of the diploma, we need to resolve that. > *David Chadwick:* `@JoeAndrieu`. I know how. The metadata of the proof is separate from the metadata of the credential. **Joe Andrieu:** if `@context` is not required in that VC property, how do you round-trip on a credential with a custom `@context`.. **Michael Prorock:** if you go from a VC in JSON-LD to a VC-JWT,.... **Joe Andrieu:** so I think it may fail that black box. **David Chadwick:** think I know how to solve this issue - the claims about the subject and in the VCDM are distinct from the claims used for the proof. > *Mahmoud Alkhraishi:* to clarify you mean metadata about credential subject vs metadata about vc?. **David Chadwick:** a number of incidents where we talk about claims of the VC that are actually metadata of the credential, has its own metadata such as its serial number or issuance data. > *Orie Steele:* See this issue filed by ivan.... seems relevant: [https://github.com/w3c/vc-data-model/issues/1044](https://github.com/w3c/vc-data-model/issues/1044). **David Chadwick:** think JFF got it right when they put the certificate identifier as the credential identifier, each proof would have a different identifier but the credential data would have the same number. > *Kristina Yasuda:* see [https://github.com/w3c/vc-jwt/issues/53](https://github.com/w3c/vc-jwt/issues/53).

w3c / vc-jose-cose

F2F mapping converstation #53