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 <rifaat.s.i...@gmail.com> 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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth