The "re-auth" problem is an interesting one, the question of how does the
client know if the user new authentication matches the previous one for
something like mailbox access? What happens if the end user doesn't auth as
the same user? If you really need this I think Connect solves this well, and
OAuth is currently ocmpletely silent on this.
I don't think the userID indication to the client really does what we want.
If we want to do this in OAuth I think it would be better to hand the expired
token back to the AS and say "this is the user I expect" and have the AS fail
if that doesn't match.
-bill
On Thursday, May 15, 2014 9:54 AM, Mike Jones <michael.jo...@microsoft.com>
wrote:
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:oauth-boun...@ietf.org] 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
phil.h...@oracle.com
On May 15, 2014, at 9:14 AM, Thomas Hardjono <hardj...@mit.edu> 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:oauth-boun...@ietf.org] 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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
