>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>: > This was proposed > 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> > 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-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-jones-oauth-resource-metadata-00.html > > -- Mike > > P.S. This notice was also posted at http://self-issued.info/?p=1591 and as > @selfissued<https://twitter.com/selfissued> <https://twitter.com/selfissued>. > > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > -- > Vladimir Dzhuvinov > > _______________________________________________ > 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 > -- Nat Sakimura Chairman of the Board, OpenID Foundation
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
