[OAUTH-WG] Re: WGLC for SD-JWT

[Dick Hardt <[e-mail]>]

A while ago in an in-person meeting I provided feedback that the
introduction was difficult to parse. It still is. A few comments inserted
to illustrate.

I'll raise my hand to provide alternative text if the authors are
interested.

/Dick


> 1.
> <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-12.html#section-1>
> Introduction
>
> <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-12.html#name-introduction>This
> document specifies conventions for creating JSON Web Signature (JWS) [
> RFC7515
> <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-12.html#RFC7515>
> ] structures with JSON [RFC8259
> <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-12.html#RFC8259>
> ] objects as the payload while supporting selective disclosure of
> individual elements of that JSON. Because JSON Web Token (JWT) [RFC7519
> <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-12.html#RFC7519>
> ] is a very prevalent application of JWS with a JSON payload, the
> selective disclosure of JWT claims receives primary treatment herein.
> However, that does not preclude the mechanism's applicability to other
> applications of JWS with JSON payloads.
>

The last two sentences add alot of noise to the first paragraph of what
this document is all about


> The JSON-based representation of claims in a signed JWT is secured against
> modification using JWS digital signatures. A consumer of a signed JWT that
> has checked the signature can safely assume that the contents of the token
> have not been modified. However, anyone receiving an unencrypted JWT can
> read all the claims. Likewise, anyone with the decryption key receiving
> encrypted JWT can also read all the claims.
>


> One of the common use cases of a signed JWT is representing a user's
> identity. As long as the signed JWT is one-time use, it typically only
> contains those claims the user has consented to disclose to a specific
> Verifier. However, there is an increasing number of use cases where a
> signed JWT is created once and then used a number of times by the user (the
> "Holder" of the JWT). In such use cases, the signed JWT needs to contain
> the superset of all claims the user of the signed JWT might want to
> disclose to Verifiers at some point. The ability to selectively disclose a
> subset of these claims depending on the Verifier becomes crucial to ensure
> minimum disclosure and prevent Verifiers from obtaining claims irrelevant
> for the transaction at hand. SD-JWTs defined in this document enable such
> selective disclosure of JWT claims.
>


> One example of a multi-use JWT is an Issuer-signed credential that
> contains the claims about a subject, and whose authenticity can be
> cryptographically verified.
> Similar to the JWT specification on which it builds, this document is a
> product of the Web Authorization Protocol (OAuth) working group. However,
> while both JWT and SD-JWT have potential OAuth 2.0 applications, their
> utility and application is certainly not constrained to OAuth 2.0. JWT was
> developed as a general-purpose token format and has seen widespread usage
> in a variety of applications. SD-JWT is a selective disclosure mechanism
> for JWT and is similarly intended to be general-purpose specification.
> While JWTs with claims describing natural persons are a common use case,
> the mechanisms defined in this document are also applicable to other use
> cases.
>

The above paragraphs are background on what problem is being solved -- but
the writing is difficult to follow


> In an SD-JWT, claims can be hidden, but cryptographically protected
> against undetected modification. "Claims" here refers to both object
> properties (name/value pairs) as well as array elements. When issuing the
> SD-JWT to the Holder, the Issuer includes the cleartext counterparts of all
> hidden claims, the so-called Disclosures, outside the signed part of the
> SD-JWT.
>



> The Holder decides which claims to disclose to a particular Verifier and
> includes the respective Disclosures in the SD-JWT to that Verifier. The
> Verifier has to verify that all disclosed claim values were part of the
> original Issuer-signed JWT. The Verifier will not, however, learn any claim
> values not disclosed in the Disclosures.
>

The Holder and Verifier terms are being introduced here with no context.
The key difference in an SD-JWT and a JWT that the claims are encrypted in
what is signed is not clearly obvious.


> This document also defines a format for SD-JWTs with Key Binding
> (SD-JWT+KB). By optionally sending an SD-JWT+KB to a Verifier, the Holder
> can prove to the Verifier that they hold the private key associated to the
> SD-JWT (i.e., using the cnf claim [RFC7800
> <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-12.html#RFC7800>
> ]). The strength of the binding is conditional upon the trust in the
> protection of the private key of the key pair an SD-JWT is bound to.
>

This does not read as an introduction. Assumes significant knowledge of why
this is useful.


> SD-JWT can be used with any JSON-based representation of claims.
>

repetitive from start of intro


> This specification aims to be easy to implement and to leverage
> established and widely used data formats and cryptographic algorithms
> wherever possible.

<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-12.html#section-1-1>

<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-12.html#section-1-2>

<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-12.html#section-1-3>

<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-12.html#section-1-4>

<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-12.html#section-1-5>

<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-12.html#section-1-6>

<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-12.html#section-1-7>

<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-12.html#section-1-8>

<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-12.html#section-1-9>

<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-12.html#section-1-10>

<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-12.html#section-1-11>
Fluff -- are there specifications that aim to be difficult to implement?


On Tue, Sep 3, 2024 at 4:06 PM Brian Campbell <bcampbell=
[e-mail]> wrote:

> Thanks Rifaat & Hannes,
>
> In an effort to make the most up-to-date content available for the WGLC
> period, a -12 revision was just recently published, which contains a number
> of editorial improvements.
>
>
> https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-12.html
>
> Respectfully,
>  Brian, Kristina, and Dr. Fett
>
>
>
> On Tue, Sep 3, 2024 at 4:40 AM Rifaat Shekh-Yusef <[e-mail]>
> wrote:
>
>> All,
>>
>> As per the discussion in Vancouver, this is a WG Last Call for the *SD-JWT
>> *document.
>>
>> https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-11.html
>>
>> Please, review this document and reply on the mailing list if you have
>> any comments or concerns, by *Sep 17th*.
>>
>> Regards,
>>   Rifaat & Hannes
>> _______________________________________________
>> OAuth mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*_______________________________________________
> OAuth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>