Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

2022-06-29 Thread David Chadwick 

  
  
Hi Kristina

On 29/06/2022 02:59, Kristina Yasuda
  wrote:


  
  
  
  
Hi David,
 
The RP will know the schema of the received
  credential regardless of the number of credential types the
  Issuer is capable of issuing given each credential type has
  individual schema. What am I missing?  

  

You are missing the fact that there is not a 1:1 mapping of types
  to schemas. but rather an n:1 mapping. For example both visa and
  mastercard types could use the same creditCard schema.



  

 
I think it heavily depends on the use-case
  and it is not clear cut when and how much information does or
  does not leak. I agree we should discuss all aspects of this
  in the privacy considerations.
 
wrt mandatory and optional claims, just to
  note that there seems to be a use-case where mandatory claims
  are always revealed 
  

So where is selective disclosure in this?
Considering mDL, where there are 11 mandatory attributes and 22
  optional ones, entering a nightclub should not require me to
  reveal all 11 mandatory attributes. And having 15 blinded claim
  names in total would not allow the verifier to know which 4
  optional attributes I have, even if it can determine the
  credential type is mDL.

Blinding the claim names as mDL does is much better at privacy
  protection than the proposed draft. Have you considered a JWT-way
  of implementing this?

Kind regards
David


  
and included in SD-JWT outside
  “sd_digests”, while optional claims are hashed and included in
  “sd_digests”.
 
Best,
Kristina
 

  
From: David Chadwick
  
  
  Sent: Friday, June 24, 2022 2:16 AM
  To: Kristina Yasuda
  ; oauth@ietf.org
  Subject: Re: [OAUTH-WG] Presenting Selective
  Disclosure JWT (SD-JWT)
  

 
Hi Kristina
Yes I realise that if the RP knows the schema then it will
  know the structure of the VC. In cases where an Issuer issues
  more than one type of VC then hiding the claims names (using
  your terminology) does add value. Remember also that the
  schema will say which claim names are mandatory and which are
  optional, so in cases where a VC has a lot of optional claims
  then hiding the claim names is even more valuable.
The only case where hiding claim names has no value is when
  an issuer only issues one type of VC, and the schema makes all
  the claims mandatory.
I think for the above reasons, then hiding claim names should
  be an option.
Section 8.1 is only correct if claim names are revealed. If
  SD-JWT hid the claim names then it would not be revealing the
  schema of the JWT. (That is not to say that an RP might have
  alternate ways of discovering the schema, but SD-JWT would not
  be revealing it).
Kind regards
David

  On 23/06/2022 20:57, Kristina Yasuda
wrote:


  Hi David,
  Thank you for the feedback.
  Blinding claim names has been considered.
  Here is the issue: 
https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues/3
  We made a choice not to hash claim names
because SD-JWT already reveals information about the issuer
and the schema, and revealing the claim names does not
provide any additional information.
  The more comprehensive explanation is in
this section in the draft:

https://datatracker.ietf.org/doc/html/draft-fett-oauth-selective-disclosure-jwt-01#section-8.1
  Best,
  Kristina
   
  

  From: OAuth 
On Behalf Of David Chadwick
Sent: Thursday, June 23, 2022 10:20 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Presenting Selective
Disclosure JWT (SD-JWT)

  
   
  Hi Daniel
  Whilst I commend your initial efforts at SD, I find that
the current draft is too privacy invasive since it reveals
to the RP every property type that the user possesses, even
though it does not reveal the property values. Revealing
property types might be too privacy invasive in many cases.
Some users may not wish to reveal that they have these
properties to every RP.
  Can you investigate blinding the property types in the next
version

Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

2022-06-29 Thread Nikos Fotiou 
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  
Sent: Wednesday, June 29, 2022 5:32 AM
To: Nikos Fotiou ; Daniel Fett 
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  On Behalf Of Nikos Fotiou
Sent: Tuesday, June 28, 2022 5:47 AM
To: Daniel Fett 
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%2FTKxcnNUnuqw

Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

2022-06-28 Thread Kristina Yasuda 
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  On Behalf Of Nikos Fotiou
Sent: Tuesday, June 28, 2022 5:47 AM
To: Daniel Fett 
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  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&

Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

2022-06-28 Thread Kristina Yasuda 
Hi David,

The RP will know the schema of the received credential regardless of the number 
of credential types the Issuer is capable of issuing given each credential type 
has individual schema. What am I missing?

I think it heavily depends on the use-case and it is not clear cut when and how 
much information does or does not leak. I agree we should discuss all aspects 
of this in the privacy considerations.

wrt mandatory and optional claims, just to note that there seems to be a 
use-case where mandatory claims are always revealed and included in SD-JWT 
outside "sd_digests", while optional claims are hashed and included in 
"sd_digests".

Best,
Kristina

From: David Chadwick 
Sent: Friday, June 24, 2022 2:16 AM
To: Kristina Yasuda ; oauth@ietf.org
Subject: Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)


Hi Kristina

Yes I realise that if the RP knows the schema then it will know the structure 
of the VC. In cases where an Issuer issues more than one type of VC then hiding 
the claims names (using your terminology) does add value. Remember also that 
the schema will say which claim names are mandatory and which are optional, so 
in cases where a VC has a lot of optional claims then hiding the claim names is 
even more valuable.

The only case where hiding claim names has no value is when an issuer only 
issues one type of VC, and the schema makes all the claims mandatory.

I think for the above reasons, then hiding claim names should be an option.

Section 8.1 is only correct if claim names are revealed. If SD-JWT hid the 
claim names then it would not be revealing the schema of the JWT. (That is not 
to say that an RP might have alternate ways of discovering the schema, but 
SD-JWT would not be revealing it).

Kind regards

David
On 23/06/2022 20:57, Kristina Yasuda wrote:
Hi David,
Thank you for the feedback.
Blinding claim names has been considered.
Here is the issue: 
https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues/3<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Foauthstuff%2Fdraft-selective-disclosure-jwt%2Fissues%2F3&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7C91a63c11ada4480c3c4708da55c231d3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637916589809815666%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=0USscKr1kliJkKxqOT4l7DqodzKAHV3vkm%2FJfzAAJDw%3D&reserved=0>
We made a choice not to hash claim names because SD-JWT already reveals 
information about the issuer and the schema, and revealing the claim names does 
not provide any additional information.
The more comprehensive explanation is in this section in the draft: 
https://datatracker.ietf.org/doc/html/draft-fett-oauth-selective-disclosure-jwt-01#section-8.1<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-fett-oauth-selective-disclosure-jwt-01%23section-8.1&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7C91a63c11ada4480c3c4708da55c231d3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637916589809815666%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=piNmCIGkEUcN73EdKiAABIBMQqqaM97o%2FXPr4YbZCfc%3D&reserved=0>
Best,
Kristina

From: OAuth <mailto:oauth-boun...@ietf.org> On Behalf 
Of David Chadwick
Sent: Thursday, June 23, 2022 10:20 AM
To: oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)


Hi Daniel

Whilst I commend your initial efforts at SD, I find that the current draft is 
too privacy invasive since it reveals to the RP every property type that the 
user possesses, even though it does not reveal the property values. Revealing 
property types might be too privacy invasive in many cases. Some users may not 
wish to reveal that they have these properties to every RP.

Can you investigate blinding the property types in the next version please?

Kind regards

David
On 23/06/2022 17:32, Daniel Fett wrote:

All,

Kristina and I would like to bring to your attention a new draft that we have 
been working on with many others over the past weeks. "Selective Disclosure JWT 
(SD-JWT)" describes a format for signed JWTs that support selective disclosure 
(SD-JWT), enabling sharing only a subset of the claims included in the original 
signed JWT instead of releasing all the claims to every verifier.

https://www.ietf.org/archive/id/draft-fett-oauth-selective-disclosure-jwt-01.html<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-fett-oauth-selective-disclosure-jwt-01.html&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7C91a63c11ada4480c3c4708da55c231d3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637916589809815666%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3

Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

2022-06-28 Thread Nikos Fotiou 
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 - http://pages.cs.aueb.gr/~fotiou
Researcher - Mobile Multimedia Laboratory
Athens University of Economics and Business
https://mm.aueb.gr

> On 28 Jun 2022, at 2:54 PM, Daniel Fett  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://www.w3.org/TR/vc-data-model/#proof-formats) “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

Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

2022-06-28 Thread Daniel Fett 

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://www.w3.org/TR/vc-data-model/#proof-formats) “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

Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

2022-06-28 Thread 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://www.w3.org/TR/vc-data-model/#proof-formats) “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.

 

Finally, I would like to bring to everybody’s attention this draft 
https://w3c-ccg.github.io/Merkle-Disclosure-2021/jwp/ It has the same goals as 
SD-JWT but it makes no modification to the actual JSON object, instead all 
information required to validate a proof is in the signature. I believe this is 
a cleaner approach since you can re-use existing infrastructure simply by 
adding support for a new signature type. 

 

Best,

Nikos

 

From: Daniel Fett  
Sent: Tuesday, June 28, 2022 1:17 PM
To: Nikos Fotiou ; oauth@ietf.org
Subject: Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

 

Hi Nikos,

the requirement for putting the claims into a separate structure becomes more 
obvious from your example.

On the surface, you can see that the data types don't match the specifications 
- the email address is not an email address, the phone number is not a phone 
number, the address even has a completely different data type.

Digging a bit deeper, the JWT in your example suggests that the issuer attests 
that the user has the sub 'LbnhkOr5oS7KjeUrxezAu8TG0CpWz0jSixy6tffuo04' and the 
given_name 'fUMdn88aaoyKTHrvZd6AuLmPraGhPJ0zF5r_JhxCVZs'. This is absolutely 
not what the issuer wants to attest, but not clearly communicated in the JWT. 
This is ambgiuous to anyone interpreting the JWT, especially if they are 
unaware of the SD-JWT format, and various security problems can arise from 
that. Putting the claims into a separate container makes the distinction 
explicit.

Conversely, there is not really much to gain here by adhering - on the surface! 
- to an existing structure. We are messing up types, as described above, and 
contents. Anybody interpreting an SD-JWT needs to implement verification logic 
anyway, so why bother hiding the differences behind a familiar looking 
structure? I don't think that this impedes integration, but rather fosters 
clean implementations.

A verification algorithm can merge the released claims into the plain-text 
claims and produce a plain-text JSON that can then be fed into whatever 
algorithm uses the contents. This is a trivial programming exercise.

Regarding your proposal with the array below: This format does not work well 
with structured claims (see Examples 2 and 3).

-Daniel

 

Am 28.06.22 um 10:30 schrieb Nikos Fotiou:

  

> If the SD-JWT-R does not contain all claim names, the verifier might not be 
> able to tell whether a particular claim is an SD claim or a plain-text claim.

 

It is not obvious (at least to me) why the verifier needs to know that. 
Moreover, I agree that this approach is unambiguous but, IMHO, it is not clean 
and it impedes integration (e.g., as I wrote in the previous email example 4 is 
(probably) wrong). If a verifier really needs to know which claim is an SD 
claim, I believe a cleaner approach is to indicate this using out-of-band 
mechanisms, e.g., provide this information in a schema, in a VC “context”,  
documentation.  Alternatively,  `sd_digests` can be  just as an array that 
indicates the SD claims, e.g., example 1 in section 5.2 could be:

 

{

"iss":  <https://example.com/issuer> https://example.com/issuer,

"sub_jwk": {

"kty": "RSA",

"n": 
"pm4bOHBg-oYhAyPWzR56AWX3rUIXp11_ICDkGgS6W3ZWLts-hzwI3x65659kg4hVo9dbGoCJE3ZGF_eaetE30UhBUEgpGwrDrQiJ9zqprmcFfr3qvvkGjtth8Zgl1eM2bJcOwE7PCBHWTKWYs152R7g6Jg2OVph-a8rq-q79MhKG5QoW_mTz10QT_6H4c7PjWG1fjh8hpWNnbP_pv6d1zSwZfc5fl6yVRL0DV0V3lGHKe2Wqf_eNGjBrBLVklDTk8-stX_MWLcR-EGmXAOv0UBWitS_dXJKJu-vXJyw14nHSGuxTIK2hx1pttMft9CsvqimXKeDTU14qQL1eE7ihcw",

"e": "AQAB"

},

"hash_alg": "sha-256",

"iat": 1516239022,

"exp": 1516247022,

"sub": "LbnhkOr5oS7KjeUrxezAu8TG0CpWz0jSixy6tffuo04",

"given_name": "fUMdn88aaoyKTHrvZd6AuLmPraGhPJ0zF5r_JhxCVZs",

"family_name": "9h5vgv6TpFV6GmnPtugiMLl5tHetHeb5X_2cKHjN7cw",

"email": "fPZ92dtYMCN2Nb-2ac_zSH19p4yakUXrZl_-wSgaazA",

"phone_number": "QdSffzNzzd0n60MsSmuiKj6Y6Enk2b-BS-KtEePde5M",

"address": "JFu99NUXPq55f6DFBZ22rMkxMNHayCrfPG0FDsqbyDs"

Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

2022-06-28 Thread Daniel Fett 

Hi Nikos,

the requirement for putting the claims into a separate structure becomes 
more obvious from your example.


On the surface, you can see that the data types don't match the 
specifications - the email address is not an email address, the phone 
number is not a phone number, the address even has a completely 
different data type.


Digging a bit deeper, the JWT in your example suggests that the issuer 
attests that the user has the sub 
'LbnhkOr5oS7KjeUrxezAu8TG0CpWz0jSixy6tffuo04' and the given_name 
'fUMdn88aaoyKTHrvZd6AuLmPraGhPJ0zF5r_JhxCVZs'. This is absolutely not 
what the issuer wants to attest, but not clearly communicated in the 
JWT. This is ambgiuous to anyone interpreting the JWT, especially if 
they are unaware of the SD-JWT format, and various security problems can 
arise from that. Putting the claims into a separate container makes the 
distinction explicit.


Conversely, there is not really much to gain here by adhering - on the 
surface! - to an existing structure. We are messing up types, as 
described above, and contents. Anybody interpreting an SD-JWT needs to 
implement verification logic anyway, so why bother hiding the 
differences behind a familiar looking structure? I don't think that this 
impedes integration, but rather fosters clean implementations.


A verification algorithm can merge the released claims into the 
plain-text claims and produce a plain-text JSON that can then be fed 
into whatever algorithm uses the contents. This is a trivial programming 
exercise.


Regarding your proposal with the array below: This format does not work 
well with structured claims (see Examples 2 and 3).


-Daniel


Am 28.06.22 um 10:30 schrieb Nikos Fotiou:


> If the SD-JWT-R does not contain all claim names, the verifier might 
not be able to tell whether a particular claim is an SD claim or a 
plain-text claim.


It is not obvious (at least to me) why the verifier needs to know 
that. Moreover, I agree that this approach is unambiguous but, IMHO, 
it is not clean and it impedes integration (e.g., as I wrote in the 
previous email example 4 is (probably) wrong). If a verifier really 
needs to know which claim is an SD claim, I believe a cleaner approach 
is to indicate this using out-of-band mechanisms, e.g., provide this 
information in a schema, in a VC “context”,  documentation. 
 Alternatively,  `sd_digests` can be  just as an array that indicates 
the SD claims, e.g., example 1 in section 5.2 could be:


{

"iss": https://example.com/issuer <https://example.com/issuer>,

"sub_jwk": {

"kty": "RSA",

"n": 
"pm4bOHBg-oYhAyPWzR56AWX3rUIXp11_ICDkGgS6W3ZWLts-hzwI3x65659kg4hVo9dbGoCJE3ZGF_eaetE30UhBUEgpGwrDrQiJ9zqprmcFfr3qvvkGjtth8Zgl1eM2bJcOwE7PCBHWTKWYs152R7g6Jg2OVph-a8rq-q79MhKG5QoW_mTz10QT_6H4c7PjWG1fjh8hpWNnbP_pv6d1zSwZfc5fl6yVRL0DV0V3lGHKe2Wqf_eNGjBrBLVklDTk8-stX_MWLcR-EGmXAOv0UBWitS_dXJKJu-vXJyw14nHSGuxTIK2hx1pttMft9CsvqimXKeDTU14qQL1eE7ihcw",


"e": "AQAB"

    },

"hash_alg": "sha-256",

"iat": 1516239022,

"exp": 1516247022,

"sub": "LbnhkOr5oS7KjeUrxezAu8TG0CpWz0jSixy6tffuo04",

"given_name": "fUMdn88aaoyKTHrvZd6AuLmPraGhPJ0zF5r_JhxCVZs",

"family_name": "9h5vgv6TpFV6GmnPtugiMLl5tHetHeb5X_2cKHjN7cw",

"email": "fPZ92dtYMCN2Nb-2ac_zSH19p4yakUXrZl_-wSgaazA",

"phone_number": "QdSffzNzzd0n60MsSmuiKj6Y6Enk2b-BS-KtEePde5M",

"address": "JFu99NUXPq55f6DFBZ22rMkxMNHayCrfPG0FDsqbyDs",

"birthdate": "Ia1Tc6_Xnt5CJc2LtKcu6Wvqr42glBGGcjGOye8Zf3U",

"sd_digests":["sub", "given_name", "family_name", "email", 
"phone_number", "address", "birthdate"]


}

Best,

Nikos

*From:*OAuth  *On Behalf Of *Daniel Fett
*Sent:* Tuesday, June 28, 2022 10:30 AM
*To:* oauth@ietf.org
*Subject:* Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

Hi Nikos,

Am 24.06.22 um 16:16 schrieb Nikos Fotiou:

Hi,

I was wondering what is the reason for introducing the sd_digests
claim. I think it complicates integration with existing systems.
For example, I am pretty sure that the VC included in Example 4 is
wrong. Since the verifier can learn from the SD-JWT-RELEASE which
claims are hashed, why is it necessary to nest them under the
sd_digests claim?

The idea is to have a clean, unambiguous seperation between the two. 
If the SD-JWT-R does not contain all claim names, the verifier might 
not be able to tell whether a particular claim is an SD claim or a 
plain-text claim.


Also a small detail: if you decode the token at the end of section
5.2, instead of "sd_digests" it uses "_sd"

Good catch, we'll update the examples. We have opened an issue for 
that: 
htt

Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

2022-06-28 Thread Neil Madden 

> On 28 Jun 2022, at 10:28, Neil Madden  wrote:
> 
> 
>> On 28 Jun 2022, at 08:37, Daniel Fett > > wrote:
>> 
>> […]
>> 
>>> 
>>> The fact that HASH(SALT | CLAIM-VALUE) is vulnerable to length extension 
>>> attacks is also troubling, even if I can’t see an immediate attack. But 
>>> it’s a weird property that Bob, for example, could make a commitment to 
>>> some extension of one of Alice’s claims without actually knowing her claim 
>>> value.
>> That would mean the Bob would need to be an issuer in this case? 
> 
> Well, that depends on whether the claims are blinded from the issuer too or 
> not? I don’t think the draft specifies this at the moment. I can imagine a 
> privacy-oriented OIDC OP that only stores/sees blinded identity claims for 
> example.

Ah, I’ve just seen in section 5.1.1 that the issuer actually hashes a JSON 
array rather than the raw concatenation of the salt and the claim value, so 
this is not vulnerable to length extension anyway. That section also addresses 
my other comments about entropy and unique salts per claim. I’d still recommend 
using HMAC anyway, for the reasons I added in my last message, but it’s not as 
urgent.

— Neil___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

2022-06-28 Thread Neil Madden 

> On 28 Jun 2022, at 08:37, Daniel Fett  
> wrote:
> 
> […]
> 
>> 
>> The fact that HASH(SALT | CLAIM-VALUE) is vulnerable to length extension 
>> attacks is also troubling, even if I can’t see an immediate attack. But it’s 
>> a weird property that Bob, for example, could make a commitment to some 
>> extension of one of Alice’s claims without actually knowing her claim value.
> That would mean the Bob would need to be an issuer in this case? 

Well, that depends on whether the claims are blinded from the issuer too or 
not? I don’t think the draft specifies this at the moment. I can imagine a 
privacy-oriented OIDC OP that only stores/sees blinded identity claims for 
example.

>> 
>> You can address both of these issues by instead using a compactly committing 
>> PRF [1], such as HMAC- i.e., HMAC-HASH(SALT, CLAIM-VALUE) rather than simple 
>> prefix hash.
> Given the advantages, we will consider using an HMAC. 

Great, I think using HMAC just eliminates any concerns, however remote. This 
use of HMAC is also identical to HKDF-Extract, which has quite a lot of 
argument backing it up for being a strong computational extractor, where simple 
hashes are often not (see RFC 5869 and particularly the original paper it links 
to, which discusses these topics in depth).

[…]

— Neil___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

2022-06-28 Thread Nikos Fotiou 
Hi Daniel,

 

> If the SD-JWT-R does not contain all claim names, the verifier might not be 
> able to tell whether a particular claim is an SD claim or a plain-text claim.

 

It is not obvious (at least to me) why the verifier needs to know that. 
Moreover, I agree that this approach is unambiguous but, IMHO, it is not clean 
and it impedes integration (e.g., as I wrote in the previous email example 4 is 
(probably) wrong). If a verifier really needs to know which claim is an SD 
claim, I believe a cleaner approach is to indicate this using out-of-band 
mechanisms, e.g., provide this information in a schema, in a VC “context”,  
documentation.  Alternatively,  `sd_digests` can be  just as an array that 
indicates the SD claims, e.g., example 1 in section 5.2 could be:

 

{

"iss":  <https://example.com/issuer> https://example.com/issuer,

"sub_jwk": {

"kty": "RSA",

"n": 
"pm4bOHBg-oYhAyPWzR56AWX3rUIXp11_ICDkGgS6W3ZWLts-hzwI3x65659kg4hVo9dbGoCJE3ZGF_eaetE30UhBUEgpGwrDrQiJ9zqprmcFfr3qvvkGjtth8Zgl1eM2bJcOwE7PCBHWTKWYs152R7g6Jg2OVph-a8rq-q79MhKG5QoW_mTz10QT_6H4c7PjWG1fjh8hpWNnbP_pv6d1zSwZfc5fl6yVRL0DV0V3lGHKe2Wqf_eNGjBrBLVklDTk8-stX_MWLcR-EGmXAOv0UBWitS_dXJKJu-vXJyw14nHSGuxTIK2hx1pttMft9CsvqimXKeDTU14qQL1eE7ihcw",

"e": "AQAB"

},

"hash_alg": "sha-256",

"iat": 1516239022,

"exp": 1516247022,

"sub": "LbnhkOr5oS7KjeUrxezAu8TG0CpWz0jSixy6tffuo04",

"given_name": "fUMdn88aaoyKTHrvZd6AuLmPraGhPJ0zF5r_JhxCVZs",

"family_name": "9h5vgv6TpFV6GmnPtugiMLl5tHetHeb5X_2cKHjN7cw",

"email": "fPZ92dtYMCN2Nb-2ac_zSH19p4yakUXrZl_-wSgaazA",

"phone_number": "QdSffzNzzd0n60MsSmuiKj6Y6Enk2b-BS-KtEePde5M",

"address": "JFu99NUXPq55f6DFBZ22rMkxMNHayCrfPG0FDsqbyDs",

"birthdate": "Ia1Tc6_Xnt5CJc2LtKcu6Wvqr42glBGGcjGOye8Zf3U",

"sd_digests":["sub", "given_name", "family_name", "email", "phone_number", 
"address", "birthdate"]

}

 

Best,

Nikos

 

From: OAuth  On Behalf Of Daniel Fett
Sent: Tuesday, June 28, 2022 10:30 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

 

Hi Nikos,

Am 24.06.22 um 16:16 schrieb Nikos Fotiou:

Hi,
I was wondering what is the reason for introducing the sd_digests claim. I 
think it complicates integration with existing systems. For example, I am 
pretty sure that the VC included in Example 4 is wrong. Since the verifier can 
learn from the SD-JWT-RELEASE which claims are hashed, why is it necessary to 
nest them under the sd_digests claim?

The idea is to have a clean, unambiguous seperation between the two. If the 
SD-JWT-R does not contain all claim names, the verifier might not be able to 
tell whether a particular claim is an SD claim or a plain-text claim. 



Also a small detail: if you decode the token at the end of section 5.2, instead 
of "sd_digests" it uses "_sd"

Good catch, we'll update the examples. We have opened an issue for that:  
<https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues/79> 
https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues/79

Thanks,
Daniel

 
 
Best,
Nikos
--
Nikos Fotiou -  <http://pages.cs.aueb.gr/~fotiou> 
http://pages.cs.aueb.gr/~fotiou
Researcher - Mobile Multimedia Laboratory
Athens University of Economics and Business
 <https://mm.aueb.gr> https://mm.aueb.gr
 

On 23 Jun 2022, at 7:32 PM, Daniel Fett  
<mailto:mail=40danielfett...@dmarc.ietf.org> 
 wrote:
 
All,
 
Kristina and I would like to bring to your attention a new draft that we have 
been working on with many others over the past weeks. "Selective Disclosure JWT 
(SD-JWT)" describes a format for signed JWTs that support selective disclosure 
(SD-JWT), enabling sharing only a subset of the claims included in the original 
signed JWT instead of releasing all the claims to every verifier. 
 
 
<https://www.ietf.org/archive/id/draft-fett-oauth-selective-disclosure-jwt-01.html>
 
https://www.ietf.org/archive/id/draft-fett-oauth-selective-disclosure-jwt-01.html
 
Initial feedback we got was positive and we now would like to hear from the 
working group with the eventual goal of asking for working group adoption.
 
Issues are tracked in our GitHub repository:  
<https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues> 
https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues
 
The approach to selective disclosure described in the document is based on 
salted hashes. We have discussed and explored other approaches based on 
encryption as well. If you are interested in following this discussion, we 
would l

Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

2022-06-28 Thread Daniel Fett 

Hi Neil,

thanks for your feedback! The security considerations are certainly far 
from complete in this first draft (and didn't intend to be). Your 
comments will help us to improve this part of the draft.


Am 23.06.22 um 20:52 schrieb Neil Madden:
I’m not entirely sure the OAuth WG is a suitable venue for this kind 
of document. It should at least get some review from CFRG, to get 
feedback on the crypto aspects.


That would certainly be appropriate!



I have some initial comments about the cryptography being used.

Commitments to claim values are of the form HASH(SALT | CLAIM-VALUE), 
but this does not necessarily commit the sender to CLAIM-VALUE. In 
section 7.4, I think you need to say that HASH must be collision 
resistant - otherwise the user can find two (salt, claim-value) pairs 
that collide and get the issuer to sign one and then reveal the other 
pair to the downstream party.

+1


The fact that HASH(SALT | CLAIM-VALUE) is vulnerable to length 
extension attacks is also troubling, even if I can’t see an immediate 
attack. But it’s a weird property that Bob, for example, could make a 
commitment to some extension of one of Alice’s claims without actually 
knowing her claim value.

That would mean the Bob would need to be an issuer in this case?


You can address both of these issues by instead using a compactly 
committing PRF [1], such as HMAC- i.e., HMAC-HASH(SALT, CLAIM-VALUE) 
rather than simple prefix hash.

Given the advantages, we will consider using an HMAC.


It doesn’t seem great to say that you can use any hash algorithm in 
the IANA registry, but then to rule out half of them as being not 
suitable in the security considerations - this list may go out of date 
as other hash algorithms are broken. Is it possible to update the IANA 
registry with a Recommended Y/N column? Also, shake128 and shake256 
are not collision-resistant hash functions, they are XOFs that can 
produce any length of output - e.g. shake128 with a 32-bit output 
would not be collision-resistant and thus would not be at all suitable 
for this usage. Given these considerations, I might be tempted to 
create a new IANA registry, or perhaps just pick one good hash 
function. (Or maybe just use the same hash algorithm as the signature?)


I don't know of such a registry, but I'm certain the current limitations 
in our spec are not sufficient and we need to improve this.


-Daniel

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

2022-06-28 Thread Daniel Fett 

Hi Nikos,

Am 24.06.22 um 16:16 schrieb Nikos Fotiou:

Hi,
I was wondering what is the reason for introducing the sd_digests claim. I 
think it complicates integration with existing systems. For example, I am 
pretty sure that the VC included in Example 4 is wrong. Since the verifier can 
learn from the SD-JWT-RELEASE which claims are hashed, why is it necessary to 
nest them under the sd_digests claim?
The idea is to have a clean, unambiguous seperation between the two. If 
the SD-JWT-R does not contain all claim names, the verifier might not be 
able to tell whether a particular claim is an SD claim or a plain-text 
claim.

Also a small detail: if you decode the token at the end of section 5.2, instead of 
"sd_digests" it uses "_sd"


Good catch, we'll update the examples. We have opened an issue for that: 
https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues/79


Thanks,
Daniel



Best,
Nikos
--
Nikos Fotiou -http://pages.cs.aueb.gr/~fotiou
Researcher - Mobile Multimedia Laboratory
Athens University of Economics and Business
https://mm.aueb.gr


On 23 Jun 2022, at 7:32 PM, Daniel Fett  
wrote:

All,

Kristina and I would like to bring to your attention a new draft that we have been 
working on with many others over the past weeks. "Selective Disclosure JWT 
(SD-JWT)" describes a format for signed JWTs that support selective disclosure 
(SD-JWT), enabling sharing only a subset of the claims included in the original signed 
JWT instead of releasing all the claims to every verifier.

https://www.ietf.org/archive/id/draft-fett-oauth-selective-disclosure-jwt-01.html

Initial feedback we got was positive and we now would like to hear from the 
working group with the eventual goal of asking for working group adoption.

Issues are tracked in our GitHub 
repository:https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues

The approach to selective disclosure described in the document is based on 
salted hashes. We have discussed and explored other approaches based on 
encryption as well. If you are interested in following this discussion, we 
would like to invite you to read this 
issue:https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues/30

One main goal with this work is that the format should be easy to implement, requiring little more than a regular JWT library. Three working implementations show that this goal has been achieved:https://github.com/oauthstuff/draft-selective-disclosure-jwt#implementations  


We are looking forward to your feedback!

-Daniel


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

2022-06-24 Thread Nikos Fotiou 
Hi,
I was wondering what is the reason for introducing the sd_digests claim. I 
think it complicates integration with existing systems. For example, I am 
pretty sure that the VC included in Example 4 is wrong. Since the verifier can 
learn from the SD-JWT-RELEASE which claims are hashed, why is it necessary to 
nest them under the sd_digests claim?

Also a small detail: if you decode the token at the end of section 5.2, instead 
of "sd_digests" it uses "_sd"

Best,
Nikos
--
Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou
Researcher - Mobile Multimedia Laboratory
Athens University of Economics and Business
https://mm.aueb.gr

> On 23 Jun 2022, at 7:32 PM, Daniel Fett  
> wrote:
>
> All,
>
> Kristina and I would like to bring to your attention a new draft that we have 
> been working on with many others over the past weeks. "Selective Disclosure 
> JWT (SD-JWT)" describes a format for signed JWTs that support selective 
> disclosure (SD-JWT), enabling sharing only a subset of the claims included in 
> the original signed JWT instead of releasing all the claims to every verifier.
>
> https://www.ietf.org/archive/id/draft-fett-oauth-selective-disclosure-jwt-01.html
>
> Initial feedback we got was positive and we now would like to hear from the 
> working group with the eventual goal of asking for working group adoption.
>
> Issues are tracked in our GitHub repository: 
> https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues
>
> The approach to selective disclosure described in the document is based on 
> salted hashes. We have discussed and explored other approaches based on 
> encryption as well. If you are interested in following this discussion, we 
> would like to invite you to read this issue: 
> https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues/30
>
> One main goal with this work is that the format should be easy to implement, 
> requiring little more than a regular JWT library. Three working 
> implementations show that this goal has been achieved: 
> https://github.com/oauthstuff/draft-selective-disclosure-jwt#implementations
>
> We are looking forward to your feedback!
>
> -Daniel
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

2022-06-24 Thread David Chadwick 

  
  
Hi Denis
I tend to agree with you. Sending the same JWT to multiple
  different RPs is providing them all with a correlating handle and
  this drawback should be pointed out.
Kind regards
David

On 23/06/2022 18:04, Denis wrote:


  
  Hi Daniel,
  
  
  The key sentence from the
introduction is the following sentence:
However, when a signed JWT is
intended to be multi-use, it needs to contain the superset
of all claims 
the user might want to release to verifiers at some point.

Before diving into the proposed solution, it would be useful to
identify these multi-use cases.

Does the document intend to consider the single case of a client
making requests to two different verifiers or more elaborated
cases ?
   
If the signed JWT is intended for two verifiers, wouldn't it be
simpler for developers of clients to ask for two independent
signed JWTs 
and for developers of verifiers to verify one independent signed
JWT ?
  
If other words, what are the advantages and the drawbacks
associated with this approach ? 
  
  
  
  Denis
  
  
  

All,
  
  Kristina and I would like to bring to your attention a new
  draft that we have been working on with many others over the
  past weeks. "Selective Disclosure JWT (SD-JWT)" describes a
  format for signed JWTs that support selective disclosure
  (SD-JWT), enabling sharing only a subset of the claims
  included in the original signed JWT instead of releasing all
  the claims to every verifier. 
  
  https://www.ietf.org/archive/id/draft-fett-oauth-selective-disclosure-jwt-01.html
  
  Initial feedback we got was positive and we now would like to
  hear from the working group with the eventual goal of asking
  for working group adoption.
  
  Issues are tracked in our GitHub repository: https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues
  
  The approach to selective disclosure described in the document
  is based on salted hashes. We have discussed and explored
  other approaches based on encryption as well. If you are
  interested in following this discussion, we would like to
  invite you to read this issue: https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues/30
  
  One main goal with this work is that the format should be easy
  to implement, requiring little more than a regular JWT
  library. Three working implementations show that this goal has
  been achieved: https://github.com/oauthstuff/draft-selective-disclosure-jwt#implementations
  
  
  We are looking forward to your feedback!
  
  -Daniel
  



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

  
  
  
  
  
  ___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


  


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

2022-06-24 Thread David Chadwick 

  
  
Hi Kristina
Yes I realise that if the RP knows the schema then it will know
  the structure of the VC. In cases where an Issuer issues more than
  one type of VC then hiding the claims names (using your
  terminology) does add value. Remember also that the schema will
  say which claim names are mandatory and which are optional, so in
  cases where a VC has a lot of optional claims then hiding the
  claim names is even more valuable.
The only case where hiding claim names has no value is when an
  issuer only issues one type of VC, and the schema makes all the
  claims mandatory.
I think for the above reasons, then hiding claim names should be
  an option.
Section 8.1 is only correct if claim names are revealed. If
  SD-JWT hid the claim names then it would not be revealing the
  schema of the JWT. (That is not to say that an RP might have
  alternate ways of discovering the schema, but SD-JWT would not be
  revealing it).

Kind regards
David

On 23/06/2022 20:57, Kristina Yasuda
  wrote:


  
  
  
  
Hi David,
Thank you for the feedback.
Blinding claim names has been considered.
Here is the issue: 
https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues/3
We made a choice not to hash claim names
  because SD-JWT already reveals information about the issuer
  and the schema, and revealing the claim names does not provide
  any additional information.
The more comprehensive explanation is in
  this section in the draft:
  
https://datatracker.ietf.org/doc/html/draft-fett-oauth-selective-disclosure-jwt-01#section-8.1
Best,
Kristina
 

  
From: OAuth
   On Behalf Of 
  David Chadwick
  Sent: Thursday, June 23, 2022 10:20 AM
  To: oauth@ietf.org
  Subject: Re: [OAUTH-WG] Presenting Selective
  Disclosure JWT (SD-JWT)
  

 
Hi Daniel
Whilst I commend your initial efforts at SD, I find that the
  current draft is too privacy invasive since it reveals to the
  RP every property type that the user possesses, even though it
  does not reveal the property values. Revealing property types
  might be too privacy invasive in many cases. Some users may
  not wish to reveal that they have these properties to every
  RP.
Can you investigate blinding the property types in the next
  version please?
Kind regards
David

  On 23/06/2022 17:32, Daniel Fett wrote:

All,
  
  Kristina and I would like to bring to your attention a new
  draft that we have been working on with many others over the
  past weeks. "Selective Disclosure JWT (SD-JWT)" describes a
  format for signed JWTs that support selective disclosure
  (SD-JWT), enabling sharing only a subset of the claims
  included in the original signed JWT instead of releasing all
  the claims to every verifier.
  
  
  https://www.ietf.org/archive/id/draft-fett-oauth-selective-disclosure-jwt-01.html
  
  Initial feedback we got was positive and we now would like to
  hear from the working group with the eventual goal of asking
  for working group adoption.
  
  Issues are tracked in our GitHub repository: 
https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues
  
  The approach to selective disclosure described in the document
  is based on salted hashes. We have discussed and explored
  other approaches based on encryption as well. If you are
  interested in following this discussion, we would like to
  invite you to read this issue: 
https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues/30
  
  One main goal with this work is that the format should be easy
  to implement, requiring little more than a regular JWT
  library. Three working implementations show that this goal has
  been achieved:
  
https://github.com/oauthstuff/draft-selective-disclosure-jwt#implementations
  
  
  We are looking forward to your feedback!
  
  -Daniel

  
  
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
  

  


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

2022-06-23 Thread Kristina Yasuda 
Hi David,
Thank you for the feedback.
Blinding claim names has been considered.
Here is the issue: 
https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues/3
We made a choice not to hash claim names because SD-JWT already reveals 
information about the issuer and the schema, and revealing the claim names does 
not provide any additional information.
The more comprehensive explanation is in this section in the draft: 
https://datatracker.ietf.org/doc/html/draft-fett-oauth-selective-disclosure-jwt-01#section-8.1
Best,
Kristina

From: OAuth  On Behalf Of David Chadwick
Sent: Thursday, June 23, 2022 10:20 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)


Hi Daniel

Whilst I commend your initial efforts at SD, I find that the current draft is 
too privacy invasive since it reveals to the RP every property type that the 
user possesses, even though it does not reveal the property values. Revealing 
property types might be too privacy invasive in many cases. Some users may not 
wish to reveal that they have these properties to every RP.

Can you investigate blinding the property types in the next version please?

Kind regards

David
On 23/06/2022 17:32, Daniel Fett wrote:

All,

Kristina and I would like to bring to your attention a new draft that we have 
been working on with many others over the past weeks. "Selective Disclosure JWT 
(SD-JWT)" describes a format for signed JWTs that support selective disclosure 
(SD-JWT), enabling sharing only a subset of the claims included in the original 
signed JWT instead of releasing all the claims to every verifier.

https://www.ietf.org/archive/id/draft-fett-oauth-selective-disclosure-jwt-01.html<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-fett-oauth-selective-disclosure-jwt-01.html&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7C50dbdf4ea1f14ffa1ecc08da553cb2b5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637916016459774572%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=H%2BOYheOSWlEG6ODB4Wkd4Y3pW12EfrPGnPR12WaaCzg%3D&reserved=0>

Initial feedback we got was positive and we now would like to hear from the 
working group with the eventual goal of asking for working group adoption.

Issues are tracked in our GitHub repository: 
https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Foauthstuff%2Fdraft-selective-disclosure-jwt%2Fissues&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7C50dbdf4ea1f14ffa1ecc08da553cb2b5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637916016459774572%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=r3u6aj69vZwGBOux%2BV0gJDK2LUiB8DqYE8zOa0%2FcQYg%3D&reserved=0>

The approach to selective disclosure described in the document is based on 
salted hashes. We have discussed and explored other approaches based on 
encryption as well. If you are interested in following this discussion, we 
would like to invite you to read this issue: 
https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues/30<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Foauthstuff%2Fdraft-selective-disclosure-jwt%2Fissues%2F30&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7C50dbdf4ea1f14ffa1ecc08da553cb2b5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637916016459774572%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=AmVVvd3%2FY1f3E7C7j%2FqGovtXO3efRe6Uh%2F0kYiMBJKo%3D&reserved=0>

One main goal with this work is that the format should be easy to implement, 
requiring little more than a regular JWT library. Three working implementations 
show that this goal has been achieved: 
https://github.com/oauthstuff/draft-selective-disclosure-jwt#implementations<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Foauthstuff%2Fdraft-selective-disclosure-jwt%23implementations&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7C50dbdf4ea1f14ffa1ecc08da553cb2b5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637916016459774572%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=WA5RQfpDdTiAx8M7QTCHeXKB7w9dvwTlFbw%2FglolB%2BA%3D&reserved=0>

We are looking forward to your feedback!

-Daniel



___

OAuth mailing list

OAuth@ietf.org<mailto:OAuth@ietf.org>

https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7C50dbdf4ea1f14ffa1ecc08da553cb2b5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63791601645977

Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

2022-06-23 Thread Neil Madden 
I’m not entirely sure the OAuth WG is a suitable venue for this kind of 
document. It should at least get some review from CFRG, to get feedback on the 
crypto aspects.

I have some initial comments about the cryptography being used. 

Commitments to claim values are of the form HASH(SALT | CLAIM-VALUE), but this 
does not necessarily commit the sender to CLAIM-VALUE. In section 7.4, I think 
you need to say that HASH must be collision resistant - otherwise the user can 
find two (salt, claim-value) pairs that collide and get the issuer to sign one 
and then reveal the other pair to the downstream party.

The fact that HASH(SALT | CLAIM-VALUE) is vulnerable to length extension 
attacks is also troubling, even if I can’t see an immediate attack. But it’s a 
weird property that Bob, for example, could make a commitment to some extension 
of one of Alice’s claims without actually knowing her claim value.

You can address both of these issues by instead using a compactly committing 
PRF [1], such as HMAC- i.e., HMAC-HASH(SALT, CLAIM-VALUE) rather than simple 
prefix hash.

It doesn’t seem great to say that you can use any hash algorithm in the IANA 
registry, but then to rule out half of them as being not suitable in the 
security considerations - this list may go out of date as other hash algorithms 
are broken. Is it possible to update the IANA registry with a Recommended Y/N 
column? Also, shake128 and shake256 are not collision-resistant hash functions, 
they are XOFs that can produce any length of output - e.g. shake128 with a 
32-bit output would not be collision-resistant and thus would not be at all 
suitable for this usage. Given these considerations, I might be tempted to 
create a new IANA registry, or perhaps just pick one good hash function. (Or 
maybe just use the same hash algorithm as the signature?)

Also, I don’t think the security considerations currently say anywhere that 
salt values should be distinct for each claim. Obviously that is quite a 
crucial requirement!


[1]: https://link.springer.com/content/pdf/10.1007/978-3-319-63697-9_3.pdf 
 

— Neil

> On 23 Jun 2022, at 17:32, Daniel Fett  
> wrote:
> 
> All,
> 
> Kristina and I would like to bring to your attention a new draft that we have 
> been working on with many others over the past weeks. "Selective Disclosure 
> JWT (SD-JWT)" describes a format for signed JWTs that support selective 
> disclosure (SD-JWT), enabling sharing only a subset of the claims included in 
> the original signed JWT instead of releasing all the claims to every 
> verifier. 
> 
> https://www.ietf.org/archive/id/draft-fett-oauth-selective-disclosure-jwt-01.html
>  
> 
> 
> Initial feedback we got was positive and we now would like to hear from the 
> working group with the eventual goal of asking for   working group 
> adoption.
> 
> Issues are tracked in our GitHub repository: 
> https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues 
> 
> 
> The approach to selective disclosure described in the document is based on 
> salted hashes. We have discussed and explored other approaches based on 
> encryption as well. If you are interested in following this discussion, we 
> would like to invite you to read this issue: 
> https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues/30 
> 
> 
> One main goal with this work is that the format should be easy to implement, 
> requiring little more than a regular JWT library. Three working 
> implementations show that this goal has been achieved: 
> https://github.com/oauthstuff/draft-selective-disclosure-jwt#implementations 
> 
>  
> 
> We are looking forward to your feedback!
> 
> -Daniel
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

2022-06-23 Thread David Chadwick 

  
  
Hi Daniel
Whilst I commend your initial efforts at SD, I find that the
  current draft is too privacy invasive since it reveals to the RP
  every property type that the user possesses, even though it does
  not reveal the property values. Revealing property types might be
  too privacy invasive in many cases. Some users may not wish to
  reveal that they have these properties to every RP.
Can you investigate blinding the property types in the next
  version please?
Kind regards
David

On 23/06/2022 17:32, Daniel Fett wrote:


  
  All,

Kristina and I would like to bring to your attention a new draft
that we have been working on with many others over the past
weeks. "Selective Disclosure JWT (SD-JWT)" describes a format
for signed JWTs that support selective disclosure (SD-JWT),
enabling sharing only a subset of the claims included in the
original signed JWT instead of releasing all the claims to every
verifier. 

https://www.ietf.org/archive/id/draft-fett-oauth-selective-disclosure-jwt-01.html

Initial feedback we got was positive and we now would like to
hear from the working group with the eventual goal of asking for
working group adoption.

Issues are tracked in our GitHub repository: https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues

The approach to selective disclosure described in the document
is based on salted hashes. We have discussed and explored other
approaches based on encryption as well. If you are interested in
following this discussion, we would like to invite you to read
this issue: https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues/30

One main goal with this work is that the format should be easy
to implement, requiring little more than a regular JWT library.
Three working implementations show that this goal has been
achieved: https://github.com/oauthstuff/draft-selective-disclosure-jwt#implementations


We are looking forward to your feedback!

-Daniel

  
  
  
  ___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


  


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

2022-06-23 Thread Denis 

Hi Daniel,

The key sentence from the introduction is the following sentence:

   However, when a signed JWT is intended to be multi-use, it needs to
   contain the superset of all claims
   the user might want to release to verifiers at some point.

Before diving into the proposed solution, it would be useful to identify 
these multi-use cases.


Does the document intend to consider the single case of a client making 
requests to two different verifiers or more elaborated cases ?


If the signed JWT is intended for two verifiers, wouldn't it be simpler 
for developers of clients to ask for two independent signed JWTs

and for developers of verifiers to verify one independent signed JWT ?

If other words, what are the advantages and the drawbacks associated 
with this approach ?


Denis


All,

Kristina and I would like to bring to your attention a new draft that 
we have been working on with many others over the past weeks. 
"Selective Disclosure JWT (SD-JWT)" describes a format for signed JWTs 
that support selective disclosure (SD-JWT), enabling sharing only a 
subset of the claims included in the original signed JWT instead of 
releasing all the claims to every verifier.


https://www.ietf.org/archive/id/draft-fett-oauth-selective-disclosure-jwt-01.html

Initial feedback we got was positive and we now would like to hear 
from the working group with the eventual goal of asking for working 
group adoption.


Issues are tracked in our GitHub repository: 
https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues


The approach to selective disclosure described in the document is 
based on salted hashes. We have discussed and explored other 
approaches based on encryption as well. If you are interested in 
following this discussion, we would like to invite you to read this 
issue: 
https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues/30


One main goal with this work is that the format should be easy to 
implement, requiring little more than a regular JWT library. Three 
working implementations show that this goal has been achieved: 
https://github.com/oauthstuff/draft-selective-disclosure-jwt#implementations 



We are looking forward to your feedback!

-Daniel


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

2022-06-23 Thread Daniel Fett 

All,

Kristina and I would like to bring to your attention a new draft that we 
have been working on with many others over the past weeks. "Selective 
Disclosure JWT (SD-JWT)" describes a format for signed JWTs that support 
selective disclosure (SD-JWT), enabling sharing only a subset of the 
claims included in the original signed JWT instead of releasing all the 
claims to every verifier.


https://www.ietf.org/archive/id/draft-fett-oauth-selective-disclosure-jwt-01.html

Initial feedback we got was positive and we now would like to hear from 
the working group with the eventual goal of asking for working group 
adoption.


Issues are tracked in our GitHub repository: 
https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues


The approach to selective disclosure described in the document is based 
on salted hashes. We have discussed and explored other approaches based 
on encryption as well. If you are interested in following this 
discussion, we would like to invite you to read this issue: 
https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues/30


One main goal with this work is that the format should be easy to 
implement, requiring little more than a regular JWT library. Three 
working implementations show that this goal has been achieved: 
https://github.com/oauthstuff/draft-selective-disclosure-jwt#implementations 



We are looking forward to your feedback!

-Daniel
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth