Subject: [OAUTH-WG] OAuth Metadata Specifications Enhanced

From: Mike Jones <[email-masked]>
Date: Wed, 3 Aug 2016 20:57:02 +0000

The existing OAuth 2.0 Authorization Server Metadata<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> 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>.

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Thu, 4 Aug 2016 13:33:41 +0300

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

-- 
Vladimir Dzhuvinov

---

From: John Bradley <[email-masked]>
Date: Thu, 4 Aug 2016 16:12:59 -0400

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-masked]> wrote:
> 
> 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.
> 
>> 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.
>> 
>> *       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>
>> 
>> *       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>.
>> 
>> 
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> -- 
> Vladimir Dzhuvinov

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 17 Aug 2016 15:40:06 +0200

It does not adress the relationship between resource and scope.

Am 04.08.2016 22:12, schrieb John Bradley:
> This was proposed 
> https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-01
>
>> On Aug 4, 2016, at 6:33 AM, Vladimir Dzhuvinov 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> 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.
>>
>>> *http://tools.ietf.org/html/draft-ietf-oauth-discovery-04
>>>
>>> *http://tools.ietf.org/html/draft-jones-oauth-resource-metadata-00
>>>
>>> *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 athttp://self-issued.info/?p=1591  and as @selfissued<https://twitter.com/selfissued>.
>>>
>>>
>>>

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 17 Aug 2016 16:07:35 +0000

>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 <[email-masked]>:

> 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.
>
> 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 [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
> --
> Vladimir Dzhuvinov
>
-- 

Nat Sakimura

Chairman of the Board, OpenID Foundation

---

From: Phil Hunt <[email-masked]>
Date: Wed, 17 Aug 2016 09:24:47 -0700

+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/>[email-masked] <mailto:[email-masked]>

> On Aug 17, 2016, at 9:07 AM, Nat Sakimura <[email-masked]> 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 <[email-masked] <mailto:[email-masked]>>:
>> On Aug 4, 2016, at 6:33 AM, Vladimir Dzhuvinov <[email-masked] <mailto:[email-masked]>> wrote:
>>