On Tue, Jul 29, 2014 at 10:41 PM, Phil Hunt <phil.h...@oracle.com> wrote:
> Making everything optional achieves no benefits, you just end up with a
> complex set of options and no inter op.
>
> We had the same issue with dyn reg.
>
> I prefer to first get agreement on use case.
>
> What are the questions a caller can ask and what form of responses are
> available.
>
> Should this be limited to authz info or is this a back door for user data
> and wbfinger data?
>
> I would prefer to have agreement on use cases before picking a solution
> right now.
>
The use-case (in our case) is driving authorization at an RS from a
different vendor than the AS (we have a single AS, and everyone is free to
register a RS in the AS catalog), as explained by Justin 3 hours ago.
If the response is {"active":false}, the RS is supposed to reply with a 401
and invalid_token. This could happen if the token is invalid/unknown to the
AS, expired, or does not grant any scope registered by the calling
RS (identified by HTTP Basic auth –Client Authentication– at the endpoint).
Our "active":true responses include the "scope" claim filtered to only
include the scopes registered by the calling RS, so it can possibly return
a 403 with insufficient_scope.
They also include the "sub" claim and a custom "sub_groups" claim so the RS
can drive authorization depending on the user. Our "sub_groups" claim
includes identifiers for groups the user is a member of (so that you could
control access by groups rather than only a list of users).
Finally, we also send the "client_id" claim so the RS could identify who
uses its data, and possibly charge them accordingly (or refuse them access
if they need prior, out-of-band, approval, or they've been blacklisted,
etc.), and the "iat" and "exp" claims so they could possibly refuse access
if the token is not recent enough or will expire too soon.
In due course, we'll probably add "amr" and/or "acr" claims (or similar)
because some processes (in France for example) require the use of client
certificates, etc.
--
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
