+1. This is more in line with the alternate proposal submitted previously - and probably expressed better. :) https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00
Phil @independentid www.independentid.com <http://www.independentid.com/>phil.h...@oracle.com <mailto:phil.h...@oracle.com> > On Aug 17, 2016, at 9:07 AM, Nat Sakimura <sakim...@gmail.com> wrote: > > From a security protocols design point of view, it is a good practice to > indicate what entity in what role are going to be involved in what sequence. > So, including a resource indicator in the authorization request is good - if > it does not stop there and it is possible at all. > Resource indicator needs to support the notion of the group identifier and > allowed processing on them (combined, it sometimes is called `scope`) as > well. > > Then, there is a problem of authorization request / response not tamper > protected nor source authenticated. To be really useful, it also has to be > addressed. > > Nat > > > 2016年8月5日(金) 5:13 John Bradley <ve7...@ve7jtb.com <mailto:ve7...@ve7jtb.com>>: > This was proposed > https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-01 > <https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-01> > > It seemed to be a bit too controversial for the WG to accept at the time it > was discussed. > > John B. > >> On Aug 4, 2016, at 6:33 AM, Vladimir Dzhuvinov <vladi...@connect2id.com >> <mailto:vladi...@connect2id.com>> wrote: >> >> Thanks Mike for the updates. >> >> These two specs (along with token exchange and perhaps others) effectively >> codify "resource" as a key OAuth 2.0 property and parameter, alongside >> "scope". RFC 6749 however only specifies "scope" in authz and token requests. >> >> Have there been any thoughts how to reconcile this? >> >> Vladimir >> >> On 03/08/16 23:57, Mike Jones wrote: >>> The existing OAuth 2.0 Authorization Server >>> Metadata<https://tools.ietf.org/html/draft-ietf-oauth-discovery> >>> <https://tools.ietf.org/html/draft-ietf-oauth-discovery> specification has >>> now been joined by a related OAuth 2.0 Protected Resource >>> Metadata<https://tools.ietf.org/html/draft-jones-oauth-resource-metadata> >>> <https://tools.ietf.org/html/draft-jones-oauth-resource-metadata> >>> specification. This means that JSON metadata formats are now defined for >>> all the OAuth 2.0 parties: clients, authorization servers, and protected >>> resources. >>> >>> The most significant addition to the OAuth 2.0 Authorization Server >>> Metadata specification is enabling signed metadata, represented as claims >>> in a JSON Web Token (JWT). This is analogous to the role that the Software >>> Statement plays in OAuth Dynamic Client Registration. Signed metadata can >>> also be used for protected resource metadata. >>> >>> For use cases in which the set of protected resources used with an >>> authorization server are enumerable, the authorization server metadata >>> specification now defines the "protected_resources" metadata value to list >>> them. Likewise, the protected resource metadata specification defines an >>> "authorization_servers" metadata value to list the authorization servers >>> that can be used with a protected resource, for use cases in which those >>> are enumerable. >>> >>> The specifications are available at: >>> >>> * http://tools.ietf.org/html/draft-ietf-oauth-discovery-04 >>> <http://tools.ietf.org/html/draft-ietf-oauth-discovery-04> >>> >>> * http://tools.ietf.org/html/draft-jones-oauth-resource-metadata-00 >>> <http://tools.ietf.org/html/draft-jones-oauth-resource-metadata-00> >>> >>> HTML-formatted versions are also available at: >>> >>> * http://self-issued.info/docs/draft-ietf-oauth-discovery-04.html >>> <http://self-issued.info/docs/draft-ietf-oauth-discovery-04.html> >>> >>> * >>> http://self-issued.info/docs/draft-jones-oauth-resource-metadata-00.html >>> <http://self-issued.info/docs/draft-jones-oauth-resource-metadata-00.html> >>> >>> -- Mike >>> >>> P.S. This notice was also posted at http://self-issued.info/?p=1591 >>> <http://self-issued.info/?p=1591> and as >>> @selfissued<https://twitter.com/selfissued> >>> <https://twitter.com/selfissued>. >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://www.ietf.org/mailman/listinfo/oauth> >> >> -- >> Vladimir Dzhuvinov >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > -- > Nat Sakimura > > Chairman of the Board, OpenID Foundation > > _______________________________________________ > 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
