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

[Brian Campbell <[e-mail]>]

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 <[e-mail]> 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.
>
> 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
> [e-mail]
>
>
>
>
>
> On Mar 21, 2016, at 10:41 AM, Brian Campbell <[e-mail]>
> 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.
>
>
> ---------- Forwarded message ----------
> From: <[e-mail]>
> Date: Mon, Mar 21, 2016 at 11:31 AM
> Subject: New Version Notification for
> draft-campbell-oauth-resource-indicators-01.txt
> To: Hannes Tschofenig <[e-mail]>, Hannes Tschofenig <
> [e-mail]>, Brian Campbell <[e-mail]>,
> John Bradley <[e-mail]>
>
>
>
> 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
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>