Re: [OAUTH-WG] DPoP and MTLS - friends or foes?

[Neil Madden <[e-mail]>]

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 <bcampbell=[e-mail]> 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 <dmitryt=[e-mail]> 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
>> [e-mail]
>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth