I have written a short blog post titled "Write an OpenID Connect server in three simple steps<http://nat.sakimura.org/2013/07/28/write-openid-connect-server-in-three-simple-steps/> ".
Really, there is not much you need to on top of OAuth 2.0. It puzzles me why you need to create a draft with only minor variances in parameter names. e.g., session instead of id_token lat instead of iat alv instead of acr etc. If you change those parameter names, you will have a conformant profile of OpenID Connect. Nat 2013/7/31 John Bradley <ve7...@ve7jtb.com> > Connect dosen't require a userinfo endpoint. It is required for > interoperability if you are building an open IdP. For an enterprise type > deployment discovery, registration, userifo are all optional. > > The server is required to pass the nonce which is equivalent to a request > ID through to the JWT if the client sends it in the request. > > Justin is correct. > > John B. > > On 2013-07-30, at 5:30 PM, Phil Hunt <phil.h...@oracle.com> wrote: > > Forgot reply all. > > Phil > > Begin forwarded message: > > *From:* Phil Hunt <phil.h...@oracle.com> > *Date:* 30 July, 2013 17:25:46 GMT+02:00 > *To:* "Richer, Justin P." <jric...@mitre.org> > *Subject:* *Re: [OAUTH-WG] New Version Notification for > draft-hunt-oauth-v2-user-a4c-00.txt* > > The whole point is authn only. Many do not want or need the userinfo > endpoint. > > Phil > > On 2013-07-30, at 17:17, "Richer, Justin P." <jric...@mitre.org> wrote: > > What do you mean? You absolutely can implement a compliant OIDC server > nearly as simply as this. The things that you're missing I think are > necessary for basic interoperable functionality, and are things that other > folks using OAuth for authentication have also implemented. Namely: > > - Signing the ID token (OIDC specifies the RS256 flavor of JWS, which > is easy to do with JWT). Without a signed and verifiable ID token or > equivalent, you're asking for all kinds of token injection problems. > - Session management requests (max auth age, auth time) > - Not fall over with other parameters that you don't support (display, > prompt, etc). > > See here for more information: > > http://openid.net/specs/openid-connect-messages-1_0.html#ServerMTI > > Additionally, something that's really important to support is the User > Info Endpoint, so you can actually get user profile information beyond just > the simple "someone was here" claim -- this was the real value of Facebook > Connect from an RP's perspective. Some people will probably want to use > SCIM for this, too, and that's fine. > > -- Justin > > On Jul 30, 2013, at 10:54 AM, Phil Hunt <phil.h...@oracle.com> > wrote: > > 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 > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
