Thanks Phil & Mike, Would it possible to write this as a separate "profile" of Connect and/or UMA? The reason I ask is because a somewhat standalone document could be useful in other deployment scenarios, such as an Enterprise use-case, where some minimal OAuth2.0 "awareness" exists.
In this case, I'm thinking specifically of a Kerberos KDC server being able to return a signed/encrypted Claim (JWT) that reports the LOA value of the authentication instance (SP800-63-1 already identifies some Kerberos "levels"). The claim could then be consumed by a Connect OP or UMA AM/AS (without the OP or AS necessarily being a KDC themselves), or other downstream SPs. /thomas/ ____________________________________________ From: Bill Mills [mailto:[email protected]] Sent: Thursday, May 15, 2014 2:11 PM To: Mike Jones; Phil Hunt; Thomas Hardjono Cc: OAuth WG Subject: Re: [OAUTH-WG] AC4 and what does it solve? 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 <[email protected]> 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:[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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
