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
