Hi Kristina, Oh yes, now "merge payload" that Daniel mentions makes much more sense. IMHO the example in your email is better than example 4 . Two minor comments:
- In order for the merged payload to be a correct W3C VC, "given_name", "family_name", "birthdate" should be inside a "credentialSubject" claim - The claim names defined in "https://www.w3.org/2018/credentials/examples/v1"; are "givenName" and "familyName" (I also dislike contexts, but some may complain). Having saying these, I believe the following will produce a "merged payload" which will be a valid W3C vc-data-model VC. ... "sd_digests": { "vc":{ "credentialSubject" { "givenName": "fUMdn88aaoyKTHrvZd6AuLmPraGhPJ0zF5r_JhxCVZs", " familyName": "9h5vgv6TpFV6GmnPtugiMLl5tHetHeb5X_2cKHjN7cw", "birthdate": "fvLCnDm3r4VSYcBF3pIlXP4ulEoHuHOfG_YmFZEuxpQ" } } } Thanks, Nikos -----Original Message----- From: Kristina Yasuda <kristina.yas...@microsoft.com> Sent: Wednesday, June 29, 2022 5:32 AM To: Nikos Fotiou <fot...@aueb.gr>; Daniel Fett <f...@danielfett.de> Cc: oauth@ietf.org Subject: RE: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT) Hi Nikos, Regarding the example 4, the way vc-data-model v1.1 has defined mapping of a data-model into a JWT (https://www.w3.org/TR/vc-data-model/#json-web-token), there are (roughly) three types of claims in a JWT-VC. 1) newly defined `vc` claim that includes all properties of the vc-data-model that do not have an equivalent JWT claim (i.e. credentialSubject property is included under a `vc` claim) 2) IANA registered JWT claims that have equivalent properties in the vc-data-model (i.e. expirationDate property is mapped to an `exp` JWT claim) 3) JWT claims that do not have equivalent property defined in the vc-data-model, but are required for a complete JWT-VC, such as "nonce", "aud" to prevent replay, MITM. The logic behind example 4 in the SD-JWT draft is that we have chosen to treat `sd_digests` as a claim of type 3, hence it is a top level JWT-VC claim. Given what is (and is not) defined in W3C vc-data-model, I do not think there is right or wrong way of how to include `sd_digests` in a W3C vc-data-model signed as a JWS. "merge payload" that Daniel mentions might look something like below: Take an SD-JWT as below: "vc": { "@context": [ "https://www.w3.org/2018/credentials/v1";, "https://www.w3.org/2018/credentials/examples/v1"; ], "type": [ "VerifiableCredential", "UniversityDegreeCredential" ] }, "sd_digests": { "vc":{ "given_name": "fUMdn88aaoyKTHrvZd6AuLmPraGhPJ0zF5r_JhxCVZs", "family_name": "9h5vgv6TpFV6GmnPtugiMLl5tHetHeb5X_2cKHjN7cw", "birthdate": "fvLCnDm3r4VSYcBF3pIlXP4ulEoHuHOfG_YmFZEuxpQ" } } } And merge it into "vc": { "@context": [ "https://www.w3.org/2018/credentials/v1";, "https://www.w3.org/2018/credentials/examples/v1"; ], "type": [ "VerifiableCredential", "UniversityDegreeCredential" ], "given_name": "fUMdn88aaoyKTHrvZd6AuLmPraGhPJ0zF5r_JhxCVZs", "family_name": "9h5vgv6TpFV6GmnPtugiMLl5tHetHeb5X_2cKHjN7cw", "birthdate": "fvLCnDm3r4VSYcBF3pIlXP4ulEoHuHOfG_YmFZEuxpQ" } Majority of JWT-VC implementations do not use "@context" property of vc-data-model, so I would be reluctant to put information on which claim is an SD claim there. Quick note that we are defining SD-JWT not only for W3C vc-data-model use-cases. Best, Kristina -----Original Message----- From: OAuth <oauth-boun...@ietf.org> On Behalf Of Nikos Fotiou Sent: Tuesday, June 28, 2022 5:47 AM To: Daniel Fett <f...@danielfett.de> Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT) Hi, You are saying "merge payload". But how? In example 4 of section A.3, "given_name", "family_name", "birthdate" must be moved inside the "vc" claim to produce a valid payload. But nothing indicates that. Best, Nikos -- Nikos Fotiou - https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpages.cs.au eb.gr%2F~fotiou&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7C2cbddc2 095e3403fe52708da59044a5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63792 0172247431677%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=VAnkhAYinJ45Lphov%2Fk 8PjxIp0o%2FTKxcnNUnuqwtYfw%3D&reserved=0 Researcher - Mobile Multimedia Laboratory Athens University of Economics and Business https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.aueb.gr %2F&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7C2cbddc2095e3403fe52 708da59044a5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63792017224743167 7%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW wiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BinCDHNCcnTto54UAjz12F4KNenkmZZ e7ZcxN9lm964%3D&reserved=0 > On 28 Jun 2022, at 2:54 PM, Daniel Fett <f...@danielfett.de> wrote: > > Hi Nikos, > > Am 28.06.22 um 13:22 schrieb Nikos Fotiou: >> Hi Daniel, >> >> I just want to reverse your arguments and I will stop spamming. I will focus on your "sub" example. >> >> When a VC is encoded as a JWT, and according to specs >> (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.or g%2FTR%2Fvc-data-model%2F%23proof-formats&data=05%7C01%7CKristina.Yasuda %40microsoft.com%7C2cbddc2095e3403fe52708da59044a5e%7C72f988bf86f141af91ab2d 7cd011db47%7C1%7C0%7C637920172247431677%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&s data=nmjTY3qbX6buJpaZZyUnOTa1KVQrRY6JHXcqVQycfx8%3D&reserved=0) "sub MUST represent the id property contained in the credentialSubject" and the VC must be signed. Similarly, RFC 7253 JWT requires the "sub" claim to exist and the token to be signed. By moving "sub" to "sd_digests" you don't have a valid VC or JWT. Similarly, by merging "the released claims into the plain-text claims and produce a plain-text JSON" also results in non-valid VCs/JWTs since signature verification will fail. > There is no need to move sub to sd_digests, it can be left outside. > > The signature verification obviously must be done by the verification > algorithm before the merging. I don't imagine that the output of the > verification algorithm will be a signed JWT (since it can't produce > the signature), but just the payload. So instead of, for regular JWTs, > > receive JWT -> check signature -> extract payload -> work with > payload, > > you would here have > > receive SD-JWT -> check signature -> verify SD claims -> merge payload -> work with payload. > > -Daniel >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
