> On Jul 29, 2022, at 5:35 AM, Warren Parad <[email protected]>
> 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
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
