I would expect them to be able to co-exist in an implementation, but not both
be used on the same token. One of the implementations that I work on supports
both DPoP and MTLS on access tokens (as well as bearer tokens), and we use
metadata stored in the token objects to switch between these.
— Justin
> On Nov 12, 2021, at 11:37 AM, Dmitry Telegin
> <dmitryt=40backbase....@dmarc.ietf.org> wrote:
>
> As an implementer of one binding mechanism (DPoP) for the AS (Keycloak) that
> already features another (MTLS), I'm running into the question whether we
> should allow those two to be used simultaneously (which could be of course
> extrapolated to other hypothetical mechanisms). By "simultaneously" I mean
> binding a single token using both methods given that the material for both
> has been provided with the request.
>
> I guess currently mutual exclusivity is implied. Though in theory the "cnf"
> section of the AT could contain both "jkt" and "x5t#S256", the mechanisms are
> using different values for "token_type" and authentication scheme ("DPoP" for
> DPoP, "Bearer" for MTLS, though the latter might change to "MTLS" in the
> future) and we define no mechanism to combine them (could be "Bearer+DPoP" or
> "DPoP+MTLS" for example, which would be valid as per RFCs 7230 and 7235).
>
> I apologize if the question has been asked before; didn't find anything
> relevant in the ML. The implementer of MTLS for Keycloak also voted for
> mutually exclusive behavior.
>
> - Dmitry
> Backbase / Keycloak
>
> _______________________________________________
> 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
