Re: [OAUTH-WG] Auth Server / Resource Server Coordination

Hi Thomas— The UMA Work Group that produced the “RSR” (OAuth Resource Set Registration) spec has an outstanding issue to fix the BCP190 issue that you point out. Since it’s a backwards-incompatible change, and we are taking a semantic versioning approach, we need to plot it out appropriately. We certainly welcome other comments. The V1.0.1 draft spec is currently in a public review period <http://kantarainitiative.org/confluence/display/uma/Home>, closing Nov 2.

(Small tweak to Justin’s note: This spec is meant not to be specific to UMA, but rather to be potentially usable for “vanilla” OAuth and OpenID Connect as well.)

	Eve

> On 13 Oct 2015, at 2:10 AM, Thomas Broyer <t.broyer@gmail.com> wrote:
> 
> 
> 
> On Tue, Oct 13, 2015 at 6:14 AM Ofer Nave <odigity@gmail.com <mailto:odigity@gmail.com>> wrote:
> I know the OAuth 2.0 RFC doesn't specify any standards for coordination between the Authorization Server and the Resource Server, as it's generally assumed that both will be owned or operated by the same entity.
> 
> However, I'm building an OAuth 2.0 Auth Server, and I'd like to add a feature to make it easy for other API developers to delegate to me the responsibility of handling the auth grant process and issuing access tokens.
> 
> It seems to me that a simple version of this could be easily done by:
> 
> 1) Defining an Access Token format that contains within it everything a Resource Server will need to validate it and determine the level of access granted (list of scopes, expiration datetime, HMAC signature using a shared secret).
> 
> Either that (and I'd use JWT then, as already proposed) or have resource servers introspect tokens <https://tools.ietf.org/html/draft-ietf-oauth-introspection-11 <https://tools.ietf.org/html/draft-ietf-oauth-introspection-11>> (the latter doesn't preclude the former, but the format of the token is then just an implementation detail of the AS that the RS doesn't need to know).
> One advantage of requiring introspection is the easy support of revocation without having to create a specific API to check whether a token is revoked: you just introspect the token and directly know whether the token is valid or not, and if it's valid you get its details (and have the RS cache the response for a few seconds/minutes to avoid overloading the introspection endpoint). That being said, RS knowing the tokens are JWTs allows them to reject invalid tokens (expired, invalid signature, unexpected issuer, etc.) without the need to check for revocation at the AS.
>  
> 2) Providing a means (basic web UI) for Resource Server owners to register a set of scopes for their service, along with user-understandable descriptions of each to display when they arrive at my Authorization Endpoint.
> 
> Either a Web UI, or an API <https://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-06 <https://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-06>> (I'm not a fan of this draft, and it incidentally violates IETF's BCP190 https://tools.ietf.org/html/bcp190 <https://tools.ietf.org/html/bcp190>, but I think it's a good source of inspiration)
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com