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 <oauth-boun...@ietf.org> 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> 
<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 like to invite you to read this issue:  
<https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues/30> 
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> 
https://github.com/oauthstuff/draft-selective-disclosure-jwt#implementations 
 
We are looking forward to your feedback!
 
-Daniel
 
 
_______________________________________________
OAuth mailing list
 <mailto:OAuth@ietf.org> OAuth@ietf.org
 <https://www.ietf.org/mailman/listinfo/oauth> 
https://www.ietf.org/mailman/listinfo/oauth

 





_______________________________________________
OAuth mailing list
 <mailto:OAuth@ietf.org> OAuth@ietf.org
 <https://www.ietf.org/mailman/listinfo/oauth> 
https://www.ietf.org/mailman/listinfo/oauth

Attachment: smime.p7s
Description: S/MIME cryptographic signature

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

Reply via email to