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.bro...@gmail.com> wrote:
>
>
>
> On Tue, Oct 13, 2015 at 6:14 AM Ofer Nave <odig...@gmail.com
> <mailto:odig...@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: xmlg...@gmail.com
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
