'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 <sberyoz...@gmail.com> wrote: > 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. >> >> 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> >> phil.h...@oracle.com <mailto:phil.h...@oracle.com> >> >> >> >> >> >> On Mar 21, 2016, at 10:41 AM, Brian Campbell >>> <bcampb...@pingidentity.com <mailto:bcampb...@pingidentity.com>> 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: ** <internet-dra...@ietf.org <mailto:internet-dra...@ietf.org>> >>> Date: Mon, Mar 21, 2016 at 11:31 AM >>> Subject: New Version Notification for >>> draft-campbell-oauth-resource-indicators-01.txt >>> To: Hannes Tschofenig <hannes.tschofe...@gmx.net >>> <mailto:hannes.tschofe...@gmx.net>>, Hannes Tschofenig >>> <hannes.tschofe...@gmx.net <mailto:hannes.tschofe...@gmx.net>>, Brian >>> Campbell <brian.d.campb...@gmail.com >>> <mailto:brian.d.campb...@gmail.com>>, John Bradley <ve7...@ve7jtb.com >>> <mailto:ve7...@ve7jtb.com>> >>> >>> >>> >>> >>> 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 >>> <http://tools.ietf.org/>. >>> >>> The IETF Secretariat >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> >> >> _______________________________________________ >> 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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
