The "acr" claim (authentication context class reference) and the "acr_values"
request parameter are explicitly modelled on the SAML authentication context
work, but without the more complicated parts that didn't work out well in
practice. In this case, the request is just an ordered list of requested "acr"
values. Some of those values might be level numbers, but they also can and
will be URNs such as "urn:mace:incommon:iap:silver" or
"urn:mace:incommon:iap:bronze". In fact, the same values can be used as are
used with SAML, if it makes sense in the application context.
Phil, I don't understand why you're saying re-auth would be any different with
full Connect than with AC4. The re-auth request would be the same - an OAuth
authorization request using prompt=none - in both cases.
Cheers,
-- Mike
-----Original Message-----
From: OAuth [mailto:[email protected]] On Behalf Of Phil Hunt
Sent: Thursday, May 15, 2014 9:43 AM
To: Thomas Hardjono
Cc: OAuth WG
Subject: Re: [OAUTH-WG] AC4 and what does it solve?
Thomas,
The intent was to be compatible with Connect (by request) but to solve only the
authentication issue. That would explain the overlap with UMA.
The issue (or bug?) we face is that OAuth Clients who continue to use 6749
alone, aren't really authenticating users.
More importantly there is the question that has emerged over the past year
about whether the client should know and be able to request authentication
techniques and or levels. There is a demarcation issue to sort out.
There is also the re-authen requirement that happens a lot where clients wish
to elevate assurance level some how and may want to access a resource (not
related to user profile). In the re-auth case, you know the users profile, you
just want to confirm is this really Thomas? Just using OpenID means a much
more complicated set of requests if only because everything has to be done
twice.
Regarding AuthnContext, I understand the same issue happened and the model
chosen (for assurance) didn't work. I don't want to repeat past sins (as Brian
says). I believe LoA was the solution to the problem, but I think Mike wants to
talk some more about it - which is why it is in draft 02.
Phil
@independentid
www.independentid.com
[email protected]
On May 15, 2014, at 9:14 AM, Thomas Hardjono <[email protected]> wrote:
>
> Phil,
>
> I also just read draft-hunt-oauth-v2-user-a4c-02.
> This proposal sounds awfully close to what UMA is doing for consent
> management.
>
> The Resource Owner (RO) in UMA has the option to set access control
> policy (including expected the authentication LOA of the user/client).
> The RO also has the option to require the Client/User to provide
> Claims regarding both entities (UMA distinguishes between the Client
> and the Human person using the Client). UMA relies on OpenID-Connect
> OP to provide the Claims.
>
> btw. is your intention to create something akin to AuthnContext in
> SAML2.0?
>
> Best.
>
> /thomas/
>
> ____________________________________________
>
>
> From: OAuth [mailto:[email protected]] On Behalf Of Bill Mills
> Sent: Thursday, May 15, 2014 11:51 AM
> To: OAuth WG
> Subject: [OAUTH-WG] AC4 and what does it solve?
>
> I'm reading the AC4 draft and I want to understand the problems it's
> actually trying to solve, which isn't as clear as it could be in the
> prose. It looks like it's extending OAuth to:
>
> 1) Allowing the client to specify a desired authentication level.
> 2) Giving the client an opaque identifier to differentiate users.
> 3) Telling the client what level of authentication was used.
>
> Do I have this right?
>
> Thanks,
>
> -bill
> _______________________________________________
> OAuth mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
