Re: [OAUTH-WG] DPoP and MTLS - friends or foes?
I’m not smart enough to remember in what context I might have said this, but
I’d hazard a guess it was somehow related to service mesh.
Generally, we allow both to be specified largely because of our support for
macaroon access tokens: a proxy could transparently add a mtls binding (for ex)
to an AT as a macaroon caveat. If it first had to check whether there was some
other type of binding on it then that would make it more awkward.
So we have an implementation where there can be any number of bindings
associated with an AT and we loop through the set of keys in the “cnf” object
and ensure that each one is satisfied. (We also currently reject unrecognised
confirmation methods, I believe - on the assumption that they are all critical.
I think the specs are currently silent on what to do with an unrecognised “cnf”
value).
Macaroon ATs somewhat break the whole token_type field, as an AT can start off
as a pure bearer token and later become bound by a caveat.
— Neil
> On 12 Nov 2021, at 22:00, Brian Campbell
> wrote:
>
>
> I think Neil commented once somewhere about maybe seeing value in both at the
> same time. He's smarter than me so I don't like to contradict him. But I've
> always thought of them as mutually exclusive. And practically/pragmatically I
> think it really is one or the other.
>
>> On Fri, Nov 12, 2021 at 9:39 AM Dmitry Telegin
>> 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
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
> material for the sole use of the intended recipient(s). Any review, use,
> distribution or disclosure by others is strictly prohibited. If you have
> received this communication in error, please notify the sender immediately by
> e-mail and delete the message and any file attachments from your computer.
> Thank you.___
> 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
Re: [OAUTH-WG] DPoP and MTLS - friends or foes?
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
> 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
Re: [OAUTH-WG] DPoP and MTLS - friends or foes?
I think Neil commented once somewhere about maybe seeing value in both at
the same time. He's smarter than me so I don't like to contradict him. But
I've always thought of them as mutually exclusive. And
practically/pragmatically I think it really is one or the other.
On Fri, Nov 12, 2021 at 9:39 AM Dmitry Telegin 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
>
--
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
material for the sole use of the intended recipient(s). Any review, use,
distribution or disclosure by others is strictly prohibited. If you have
received this communication in error, please notify the sender immediately
by e-mail and delete the message and any file attachments from your
computer. Thank you._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] DPoP and MTLS - friends or foes?
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
