Re: [OAUTH-WG] Call for adoption - SD-JWT

[Warren Parad <[e-mail]>]

I too do not support adoption.

Something is "off" for me, I don't quite get the expectation on the secure
flow, in this draft, doesn't the issuer have to know the claims that could
be requested up front? If the goal is to not have the issuer contain any of
this data, but let the holder "add in their claims in a verifiable way",
the simple solution is just sharto share the access token with the actual
data. I think I would really want to see a concrete expectation about how
this would be used.

The other part is I want to challenge that it will actually have the
benefit that we want it to have (above and beyond JWEs).

For example, let's take the cornerstone argument from the draft:

> 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.
>    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.
>
>
We already have a parallel today with *scopes*. Normally, we expect that
there can be progressive scope increases, via new interactions with the
user agent and the AS. However, in practice, Resource Servers ask User
Agents to approve all scopes up front, and worse still AS don't allow the
user agent to select which scopes they want to grant. In practice, theory
and practice are not the same.

Selective disclosure is only a small subset of the problem posed by scopes,
because scopes actually convey permissions. If we are going to improve
anything, it should be restricting any and all data in not just the
id_token but also the access_token. And the solution could be this draft's
implementation, or maybe it is something similar to macaroons
<https://en.wikipedia.org/wiki/Macaroons_(computer_science)>. I don't think
this draft get's us closer to that unfortunately.

Second, I challenge the perspective of multi-use. While I completely agree
tokens are multi-use, they tend to be multi-use inside of an opaque
"platform", the user-agent interacts with RSs in the platform in an
indistinguishable way, so meaningfully, RS will request all the scopes they
know about all the time, even if they don't need them. The platform will
still request everything, and the user-agent will be forced to share the
SD-JWT-R for all the claims.

If there are multiple RS or clients involved, then the process would be to
generate multiple tokens, one for each client interaction, as we do today.
The only way out of this I can see, is like macaroons you can selectively
restrict further information for the next hop. But that's based on
delegation and legal trust, not security.

If we can have a macaroon like solution for any relevant claim in a JWT,
then I would definitely support adoption.

Alternatively, I think a much stronger solution would be to have the
encrypted claims data in the JWT, and be individually decryptable (I
haven't looked at JWEs in a while, but I didn't think that was possible)

- Warren

On Fri, Jul 29, 2022 at 2:17 AM Rifaat Shekh-Yusef <[e-mail]>
wrote:

> All,
>
> This is a call for adoption for the *SD-JWT* document
> https://datatracker.ietf.org/doc/draft-fett-oauth-selective-disclosure-jwt/
>
> Please, provide your feedback on the mailing list by *August 12th*.
>
> Regards,
>  Rifaat & Hannes
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>