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 <f...@danielfett.de> Sent: Tuesday, June 28, 2022 1:17 PM To: Nikos Fotiou <fot...@aueb.gr>; 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", "birthdate": "Ia1Tc6_Xnt5CJc2LtKcu6Wvqr42glBGGcjGOye8Zf3U", "sd_digests":["sub", "given_name", "family_name", "email", "phone_number", "address", "birthdate"] } Best, Nikos From: OAuth <mailto:oauth-boun...@ietf.org> <oauth-boun...@ietf.org> On Behalf Of Daniel Fett Sent: Tuesday, June 28, 2022 10:30 AM To: <mailto:oauth@ietf.org> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
