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> > 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 > > <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: > 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 > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
