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.aueb.gr%2F~fotiou&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7C2cbddc2095e3403fe52708da59044a5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637920172247431677%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=VAnkhAYinJ45Lphov%2Fk8PjxIp0o%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%7C2cbddc2095e3403fe52708da59044a5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637920172247431677%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BinCDHNCcnTto54UAjz12F4KNenkmZZe7ZcxN9lm964%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.org%2FTR%2Fvc-data-model%2F%23proof-formats&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7C2cbddc2095e3403fe52708da59044a5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637920172247431677%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=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
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
