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 <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
<mail=40danielfett...@dmarc.ietf.org>
<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 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
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
