The oidc specs do not allow this simple an implementation. The spec members have not shown interest in making changes as they say they are too far down the road.
I have tried to make my draft as close as possible to oidc but maybe it shouldn't be clarity wise. I am interested in what the group feels is clearest. From an ietf perspective the concern is improper use of the 6749 for authn. Is this a bug or gap we need to address? Phil On 2013-07-30, at 16:46, "Richer, Justin P." <jric...@mitre.org> wrote: > From what I read, you've defined something that uses an OAuth 2 code flow to > get an extra token which is specified as a JWT. You named it "session_token" > instead of "id_token", and you've left off the User Information Endpoint -- > but other than that, this is exactly the Basic Client for OpenID Connect. In > other words, if you change the names on things you've got OIDC, but without > the capabilities to go beyond a very basic "hey there's a user here" claim. > This is the same place that OpenID 2.0 started, and it was very, very quickly > extended with SREG, AX, PAPE, and others for it to be useful in the real > world of distributed logins. You've also left out discovery and registration > which are required for distributed deployments, but I'm guessing that those > would be modular components that could be added in (like they are in OIDC). > > I've heard complaints that OIDC is complicated, but it's really not. Yes, I > agree that the giant stack of documents is intimidating and in my opinion > it's a bit of a mess with Messages and Standard split up (but I lost that > argument years ago). However, at the core, you've got an OAuth2 authorization > server that spits out access tokens and id tokens. The id token is a JWT with > some known claims (iss, sub, etc) and is issued along side the access token, > and its audience is the *client* and not the *protected resource*. The access > token is a regular old access token and its format is undefined (so you can > use it with an existing OAuth2 server setup, like we have), and it can be > used at the User Info Endpoint to get profile information about the user who > authenticated. It could also be used for other services if your AS/IdP > protects multiple things. > > So I guess what I'm missing is what's the value proposition in this spec when > we have something that can do this already? And this doesn't seem to do > anything different (apart from syntax changes)? > > -- Justin > > On Jul 29, 2013, at 4:14 AM, Phil Hunt <phil.h...@oracle.com> wrote: > >> FYI. I have been noticing a substantial number of sites acting as OAuth >> Clients using OAuth to authenticate users. >> >> I know several of us have blogged on the issue over the past year so I won't >> re-hash it here. In short, many of us recommended OIDC as the correct >> methodology. >> >> Never-the-less, I've spoken with a number of service providers who indicate >> they are not ready to make the jump to OIDC, yet they agree there is a >> desire to support authentication only (where as OIDC does IDP-like services). >> >> This draft is intended as a minimum authentication only specification. I've >> tried to make it as compatible as possible with OIDC. >> >> For now, I've just posted to keep track of the issue so we can address at >> the next re-chartering. >> >> Happy to answer questions and discuss. >> >> Phil >> >> @independentid >> www.independentid.com >> phil.h...@oracle.com >> >> >> >> >> >> Begin forwarded message: >> >>> From: internet-dra...@ietf.org >>> Subject: New Version Notification for draft-hunt-oauth-v2-user-a4c-00.txt >>> Date: 29 July, 2013 9:49:41 AM GMT+02:00 >>> To: Phil Hunt <phil.h...@yahoo.com>, Phil Hunt <n...@ietfa.amsl.com>, Phil >>> Hunt <> >>> >>> >>> A new version of I-D, draft-hunt-oauth-v2-user-a4c-00.txt >>> has been successfully submitted by Phil Hunt and posted to the >>> IETF repository. >>> >>> Filename: draft-hunt-oauth-v2-user-a4c >>> Revision: 00 >>> Title: OAuth 2.0 User Authentication For Client >>> Creation date: 2013-07-29 >>> Group: Individual Submission >>> Number of pages: 9 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-hunt-oauth-v2-user-a4c-00.txt >>> Status: >>> http://datatracker.ietf.org/doc/draft-hunt-oauth-v2-user-a4c >>> Htmlized: http://tools.ietf.org/html/draft-hunt-oauth-v2-user-a4c-00 >>> >>> >>> Abstract: >>> This specification defines a new OAuth2 endpoint that enables user >>> authentication session information to be shared with client >>> applications. >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >> >> _______________________________________________ >> 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
