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 <[email protected]> > 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 >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> > > -- > Vladimir Dzhuvinov > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
