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

[David Waite <[e-mail]>]

> On Jul 29, 2022, at 5:35 AM, Warren Parad <wparad=[e-mail]> wrote:
> 
> 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.

To give an example of the equivalent digital representation of a physical document (such as a driver’s license), the issuing authority (e.g. motor vehicle division) would issue the SD-JWT along with equivalents for every value on the license as a subject claim, by providing them as hashed values.

Later, the party it was issued to would release this JWT, along with selectively releasing the data which correctly hashes to those values.

The trust framework itself determines which subject claims (and security claims) are required to be present or are optional. In the driver’s license context, there are standards for international licenses as well as additional country-specific information that may extend that.

This is done because network availability and privacy concerns may separate the act of acquiring the SD-JWT of a license from the issuing authority, and presenting it (such as days later during a traffic stop on a mountain road).

> 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.

Right. The desire to get more information (or in the scopes case, permissions) up-front is a consequence of trying to maintain flexibility. This is usually counterbalanced by AS policy.

Selective disclosure of claims means I can acquire a SD-JWT with all relevant information, but only disclose what is needed.

The equivalent for a SD-JWT based access token would require clients to have semantic knowledge of the access token and to be sender-vouched, but would let them selectively tune which previously granted scopes should apply to the request.

> 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.
My understanding is that macaroons are somewhat different. A macaroon would have you choose to add constraints, such as saying ‘but don’t share this data with others’ or ‘ignore that write access scope’.

SD-JWT lets you effectively remove information, such as ‘I’m not sharing this personal data with this party’ or ’this resource doesn’t see that I have write access’.

> 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.
My expectation is that for subject claims, both the end user consent and trust framework policy enforcement would indeed be the limiting factors of such overreaching. Again bringing up the driving license case above, such limits might even be regulatory.

Likewise a system using SD-JWT access tokens would have the AS set such policy, as it does today.

<snip>

-DW