Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments

[Brian Campbell]

I don't follow the reasoning about all resource servers needing to be
updated to support the new scheme before deployment could start.  Given how
6750, JWT and Introspection define things (basically as extensible with
unrecognized stuff to be ignored) , I would expect that a existing regular
RFC 6750 protected resource with no knowledge of DPoP would almost
certainly accept a dpop/jkt bound access token as though it was a bearer
token. The definition of the DPoP token_type would prescribe sending the
access token with the DPoP authorization scheme in conjunction with the
DPoP header but also say that, if that was met with a 401 WWW-Authenticate:
Bearer challenge (or the client had prior such knowledge about the RS),
that the access token could be sent using the Bearer authorization scheme.
And would work as such. There may well be some existing protected resources
that wouldn't accept a dpop/jkt bound access token but I'd say they'd be
operating erroneously and I would think it'd be a pretty small minority -
DPoP not defining a new token_type wouldn't change that situation at all
anyway. In fact, from the perspective of interoperability on roll out, I
don't see how DPoP defining a new token_type or not changes anything.
Things look a little more intentional with a new token type and auth scheme
and there might be an additional 401 challenge at first with a Bearer only
RS but I don't see how the actual inerop is any different.

The suggestion/proposal during the interim to signal to the client that the
RT had been bound was indeed to introduce a new token endpoint response
parameter[1]. Although I had an intentionally ridiculous name there to
serve as a placeholder and hopefully avoid bikeshedding the name. I will
say that doing something general (like an rt_token_type) in a specific
extension like DPoP can be pretty problematic so I think it should  need to
be something DPoP specific even if that's a little ugly.

[1] slide #23
https://datatracker.ietf.org/meeting/interim-2020-oauth-09/materials/slides-interim-2020-oauth-09-sessa-dpop.pdf


On Fri, Jun 5, 2020 at 2:17 PM George Fletcher  wrote:

> The issue I see with sticking with the DPoP token_type is that from a
> roll_out perspective, ALL resource
>
servers must be updated to support the new scheme and only then can the
> DPoP deployment start.
>
For any wide ecosystem deployment that can be problematic. I don't have any
> great suggestions:(
>
> Secondly, I do think we need a way to allow for the refresh_token to be
> bound while leaving the
>
access_tokens as bearer tokens. This adds useful security without impacting
> existing RS deployments.
>
It was unclear from our interim meeting discussion how the client knows
> whether the refresh token has
>
been bound to the public key or not. The AS can signal that the
> access_token is NOT bound by
>
returning a token_type of "bearer" but we should think about adding
> addition response fields for
>
the refresh token binding (e.g. "rt_token_type).
>
> Thanks,
> George
>
> On 5/29/20 5:50 PM, Brian Campbell wrote:
> > Apologies for the slow reply on this. No excuses other than life >
> sometimes happens. > > `token_type` is maybe not the clearest extension
> point (and one I've > arguably misused in OAuth MTLS >
> 
>  and the now defunct > Token
> Binding > 
> and >
> admitted to being on the fence about in the issue you linked to >
> 
> ). But it is the >
> extension point that was basically left in RFC 6749 to facilitate > this
> exact kind of thing (for MAC really but it's conceptually > similar in that
> it was an application level proof mechanism of sorts) > . The text from RFC
> 6749 sec 7.1 > 
>  is also copied >
> below. Note that a "client MUST NOT use an access token if it does > not
> understand the token type" so FWIW the client behaviours you > describe
> aren't in line with that. > > It still seems to be that using DPoP
> token_type is the appropriate > thing to do and that it can be defined to
> account and allow for mixed > token type situations. It would define that
> the DPoP authz scheme be > used as the authentication method to include the
> access token when > making a protected resource request. That definition
> can also include > falling back to using the Bearer authz scheme when/if so
> challenged > by a protected resource. > >
> 
>  > > 7.1
> 
> . Access Token > Types
> > 

Re: [OAUTH-WG] Product Support for RFC8414 well-known URIs

[Vladimir Dzhuvinov]

On 08/06/2020 12:15, Daniel Fett wrote:
> That would be the safe implementation, but I was wondering if
> prescribing this is a good choice for an ecosystem.

Postfix vs infix:

If we reason about the common ways ASes (as web apps) get deployed, then
(perhaps) it will become obvious which method is the most natural and
likely to be taken.

  * For an AS which gets deployed in a dedicated host, e.g. as
as.example.com , the app root is likely to be
https://as.example.com/ and hence the config URL becoming a simple
postfix.

  * Multi-tenant ASes where each AS has a dedicated domain for each
issuer also.

  * For an AS which gets deployed as part of some larger app (e.g. as
module or package) on the same host, the AS is likely to end up at
some path like https://example.com/as/ and hence the config being
easier for a postfix URL.

  * Multi-tenant ASes which share a domain - this is not clear, but I
suppose both postfix and infix can be made to work without the one
method demanding more effort.


The infix is not natural, IMO, given the way apps get deployed. Postfix
seems more natural.

I may be wrong about these assumptions. But that's one good way to
approach the problem and specify something which implementers actually
find easier / natural. This, to me, is what an "ideal" technical
standard is.

Vladimir




smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Product Support for RFC8414 well-known URIs

[Daniel Fett]

Am 09.06.20 um 00:50 schrieb Benjamin Kaduk:
> On Mon, Jun 08, 2020 at 11:15:07AM +0200, Daniel Fett wrote:
>> Hi Filip,
>>
>> Thanks for your answers!
>>
>> I'm not quite sure if the wording in my question was clear: My main
>> concern is the difference between
>> https://example.com/some/path*/.well-known/oauth-authorization-server*
>> and
>> https://example.com*/.well-known/oauth-authorization-server*/some/path,
>> i.e., the usage of the well-known URI as a postfix or as an infix.
> .well-known is only defined at the root of the path component of a URI.
> Usage such as
> https://example.com/some/path*/.well-known/oauth-authorization-server* is
> noncompliant with RFC 5785.

I know, but my impression is that since OIDC did it this way, some
clients are expecting the same behavior for RFC8414. Thus the question
if AS should be allowed or even required to offer the postfix variant in
an ecosystem.

-Daniel


-- 
https://danielfett.de

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth