Subject: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-resource-indicators-01.txt

From: Brian Campbell <[email-masked]>
Date: Mon, 21 Mar 2016 11:41:12 -0600

Very minor update to this draft before the deadline that moves Hannes from
Acknowledgements to Authors in acknowledgment of his similar work a few
years ago. Also fleshed out the IANA section with the formal registration
requests.

---------- Forwarded message ----------
From: <[email-masked]>
Date: Mon, Mar 21, 2016 at 11:31 AM
Subject: New Version Notification for
draft-campbell-oauth-resource-indicators-01.txt
To: Hannes Tschofenig <[email-masked]>, Hannes Tschofenig <
[email-masked]>, Brian Campbell <[email-masked]>,
John Bradley <[email-masked]>

A new version of I-D, draft-campbell-oauth-resource-indicators-01.txt
has been successfully submitted by Brian Campbell and posted to the
IETF repository.

Name:           draft-campbell-oauth-resource-indicators
Revision:       01
Title:          Resource Indicators for OAuth 2.0
Document date:  2016-03-21
Group:          Individual Submission
Pages:          8
URL:
https://www.ietf.org/internet-drafts/draft-campbell-oauth-resource-indicators-01.txt
Status:
https://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/
Htmlized:
https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-01
Diff:
https://www.ietf.org/rfcdiff?url2=draft-campbell-oauth-resource-indicators-01

Abstract:
   This straw-man specification defines an extension to The OAuth 2.0
   Authorization Framework that enables the client and authorization
   server to more explicitly to communicate about the protected
   resource(s) to be accessed.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Phil Hunt <[email-masked]>
Date: Mon, 21 Mar 2016 13:15:34 -0700

What about server processing rules and error conditions?  The client passes the resource in with every request. What happens if it sends a bad URL.  I see the registration for invalid_resource, but I see no processing logic for the server that describes when that is returned.  I’ll assume that is TBD.

The draft seems more finer grained than with bound configuration approach.  It suggests that the client will make a different URL request for each resource URL. This could lead to a lot of unnecessary authorizations.  I think we still have to resolve the audience to resource relationship problem and just how much detail the AS service needs to know.

I note that we have a similar issue with bound config on how granular resource URL processing is needed.  My main goal is for config to validate the domain name only as a major improvement as we just need to make sure the client is talking to a valid server and not a MITM proxy.

Finally, there is the question of optionality (in order to have backwards compatibility for static clients). If resource is optional, than how do we deal with dynamic clients that simply don’t both to use the resource parameter?  

We’re depending on client developers taking an extra step to provide the resource parameter. Maybe optionality for resource url becomes part of the client_id registration?  In contrast, config discovery is brand new, so making validation required is not such a big deal as static clients wouldn’t use discovery.

Another failure condition both drafts should consider:  
* when an authorization, token, or resource endpoint starts to fail, should the client fall back to discovery to re-verify configuration?  If so, on what errors?  A valid usecase would be a service provider deciding to re-configure its services naturally over time.  
* what are the issues when an endpoint that was part of configuration issues a re-direct? There are good and bad scenarios (e.g. to a specific cluster node), a resource that was relocated, or a hacked service that wants to steal tokens.  In these cases, should the client re-validate the new resource URI either using this draft or the bound config method?

On a positive note, unrelated to security, there have been a lot of inquiries over the years about how to authorize against on user-owned resources.  E.g. How can I ask for authorizations to Brian’s github project?  I think this is worth discussing.  Weighing the security and functionality needs would be a worthwhile discussion in BA.

Phil

@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>

> On Mar 21, 2016, at 10:41 AM, Brian Campbell <[email-masked]> wrote:
> 
> Very minor update to this draft before the deadline that moves Hannes from Acknowledgements to Authors in acknowledgment of his similar work a few years ago. Also fleshed out the IANA section with the formal registration requests. 
> 
> 
> From: <[email-masked] <mailto:[email-masked]>>
> Subject: New Version Notification for draft-campbell-oauth-resource-indicators-01.txt
> To: Hannes Tschofenig <[email-masked] <mailto:[email-masked]>>, Hannes Tschofenig <[email-masked] <mailto:[email-masked]>>, Brian Campbell <[email-masked] <mailto:[email-masked]>>, John Bradley <[email-masked] <mailto:[email-masked]>>
> 
> 
> 
> URL:            https://www.ietf.org/internet-drafts/draft-campbell-oauth-resource-indicators-01.txt <https://www.ietf.org/internet-drafts/draft-campbell-oauth-resource-indicators-01.txt>
> Status:         https://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/ <https://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/>
> Htmlized:       https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-01 <https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-01>
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-campbell-oauth-resource-indicators-01 <https://www.ietf.org/rfcdiff?url2=draft-campbell-oauth-resource-indicators-01>
> 
> Abstract:
> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> 
> The IETF Secretariat
> 
> 
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 22 Mar 2016 17:51:09 +0300

Hi

Is there any reason why 'resource' parameter can not be named 'aud' or 
'audience' ?

The text says "AS should audience restrict" the access token and that a 
token 'aud' property may be equal to this "resource" value.

I guess 'audience' is a pure access token property, while as far as 
client is concerned, it is a 'resource', but I wonder if it would be a 
bit simpler if only a single property was used.

It also might make sense to mention that the clients can have 'resource' 
values associated with them at the registration time - this can be done 
by admins, and the client applications will not have to be configured to 
send 'resource' given that AS already knows about the resource restrictions.

Cheers, Sergey

On 21/03/16 23:15, Phil Hunt wrote:
> What about server processing rules and error conditions?  The client
> passes the resource in with every request. What happens if it sends a
> bad URL.  I see the registration for invalid_resource, but I see no
> processing logic for the server that describes when that is returned.
>   I’ll assume that is TBD.
>
> The draft seems more finer grained than with bound configuration
> approach.  It suggests that the client will make a different URL request
> for each resource URL. This could lead to a lot of unnecessary
> authorizations.  I think we still have to resolve the audience to
> resource relationship problem and just how much detail the AS service
> needs to know.
>
> I note that we have a similar issue with bound config on how granular
> resource URL processing is needed.  My main goal is for config to
> validate the domain name only as a major improvement as we just need to
> make sure the client is talking to a valid server and not a MITM proxy.
>
> Finally, there is the question of optionality (in order to have
> backwards compatibility for static clients). If resource is optional,
> than how do we deal with dynamic clients that simply don’t both to use
> the resource parameter?
>
> We’re depending on client developers taking an extra step to provide the
> resource parameter. Maybe optionality for resource url becomes part of
> the client_id registration?  In contrast, config discovery is brand new,
> so making validation required is not such a big deal as static clients
> wouldn’t use discovery.
>
> * when an authorization, token, or resource endpoint starts to fail,
> should the client fall back to discovery to re-verify configuration?  If
> so, on what errors?  A valid usecase would be a service provider
> deciding to re-configure its services naturally over time.
> * what are the issues when an endpoint that was part of configuration
> issues a re-direct? There are good and bad scenarios (e.g. to a specific
> cluster node), a resource that was relocated, or a hacked service that
> wants to steal tokens.  In these cases, should the client re-validate
> the new resource URI either using this draft or the bound config method?
>
> *On a positive note, unrelated to security, there have been a lot of
> inquiries over the years about how to authorize against on user-owned
> resources.  E.g. How can I ask for authorizations to Brian’s github
> project?  I think this is worth discussing.  Weighing the security and
> functionality needs would be a worthwhile discussion in BA.*
>
> Phil
>
> @independentid
> www.independentid.com <http://www.independentid.com>
> [email-masked] <mailto:[email-masked]>
>
>
>
>
>
>> On Mar 21, 2016, at 10:41 AM, Brian Campbell
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Very minor update to this draft before the deadline that moves Hannes
>> from Acknowledgements to Authors in acknowledgment of his similar work
>> a few years ago. Also fleshed out the IANA section with the formal
>> registration requests.
>>
>>
>> From: ** <[email-masked] <mailto:[email-masked]>>
>> To: Hannes Tschofenig <[email-masked]
>> <mailto:[email-masked]>>, Hannes Tschofenig
>> <[email-masked] <mailto:[email-masked]>>, Brian
>> Campbell <[email-masked]
>> <mailto:[email-masked]>>, John Bradley <[email-masked]
>> <mailto:[email-masked]>>
>>
>>
>>
>> [email-masked] <mailto:[email-masked]>

---

From: Brian Campbell <[email-masked]>
Date: Tue, 22 Mar 2016 08:54:00 -0600

I don't consider this draft to be a direct alternative to the bound config
thing. It aims to fill a need that the WG has discussed several times
previously. It happens to also facilitate getting audience restrictions
into ATs, which address the concerns about a bad RS using an AT at a good
RS that seem to have surfaced recently (and some have gone so far as to say
isn't a 'real problem' at this time). AFAICT, bound config was put forth as
commentary or an alternative to "OAuth 2.0 Authorization Server Discovery
Metadata" that tries to check the legitimacy of an RS with webfinger.
Though, to be honest, I don't really understand what bound config solves.

The client provides the resource parameter to the token endpoint to
indicate what RS it wants a token for. Or to the authorization endpoint for
implicit (when an AT is returned as an authorization response parameter).
There shouldn't be a a need for unnecessary authorizations in most cases.

The audience to resource relationship is determined by the AS and RSs and
their deployment relationship. Pretty much how it is today. The resource
parameter just gives the client a tool to communicate the RS to the AS.

Backwards compatibility and optionality do need to be taken into account.
It's an extension. How migration and enforcement will be handled will be
policy and implementation decisions. That's just the state of things with
OAuth.

The resource parameter is available to all clients and doesn't rely on
discovery or metadata or registration.

The error condition is described in the draft as follows. Is there
something specific you believe should be addressed?

     'If the
      authorization server fails to parse the provided value or does not
      consider the resource server acceptable, it MUST reject the
      request and provide an error response with the error code
      "invalid_resource".'

On Mon, Mar 21, 2016 at 2:15 PM, Phil Hunt <[email-masked]> wrote:

> passes the resource in with every request. What happens if it sends a bad
> URL.  I see the registration for invalid_resource, but I see no processing
> logic for the server that describes when that is returned.  I’ll assume
> that is TBD.
>
> authorizations.  I think we still have to resolve the audience to resource
> relationship problem and just how much detail the AS service needs to know.
>
> resource URL processing is needed.  My main goal is for config to validate
> the domain name only as a major improvement as we just need to make sure
> the client is talking to a valid server and not a MITM proxy.
>
> Finally, there is the question of optionality (in order to have backwards
> compatibility for static clients). If resource is optional, than how do we
> deal with dynamic clients that simply don’t both to use the resource
> parameter?
>
> resource parameter. Maybe optionality for resource url becomes part of the
> client_id registration?  In contrast, config discovery is brand new, so
> making validation required is not such a big deal as static clients
> wouldn’t use discovery.
>
> so, on what errors?  A valid usecase would be a service provider deciding
> to re-configure its services naturally over time.
> wants to steal tokens.  In these cases, should the client re-validate the
> new resource URI either using this draft or the bound config method?
>
> www.independentid.com
> [email-masked]

---

From: Brian Campbell <[email-masked]>
Date: Tue, 22 Mar 2016 09:07:59 -0600

'aud' can't be used b/c it conflicts with the (yet to be registered) 'aud'
claim/parameter in https://tools.ietf.org/html/draft-ietf-oauth-jwsreq and
JWS/E requests in Connect (honestly, I'd like to use aud because we've
already done so in product but I don't think it works given the spec
landscape). Also, as you mention, 'resource' is what the client is
concerned with accessing. So the name is more representative of what it
actually is.

Yes, some more discussion of default or legacy behaviors based on config or
policy or registration is probably warranted. I suppose that begs the
question of if a OAuth Dynamic Client Registration Metadata parameter
should be defined too?

On Tue, Mar 22, 2016 at 8:51 AM, Sergey Beryozkin <[email-masked]>
wrote:

> I guess 'audience' is a pure access token property, while as far as client
> is concerned, it is a 'resource', but I wonder if it would be a bit simpler
> if only a single property was used.
>
> values associated with them at the registration time - this can be done by
> admins, and the client applications will not have to be configured to send
> 'resource' given that AS already knows about the resource restrictions.
>
> Cheers, Sergey
>
>
>
>