Re: [OAUTH-WG] Fwd: New Version Notification for draft-hunt-oauth-v2-user-a4c-00.txt

[Prateek Mishra <[e-mail]>]

Nat -

your blog posting is helpful to those of us who are looking for a 
minimal extension of OAuth with
an authenticator.  Many implementors are seeking a modest extension of 
OAuth, not an entire new protocol
stack.   I believe that is the point of Phil Hunt's proposal to the 
OAuth committee.

I do have some questions for about the statements made in the blog -

A) Can you direct me to a single OpenID Connect draft specification 
document where steps 1 and 2 are described?

B) If I implement steps 1 and 2, do I then have a conformant OpenID 
Connect implementation? Are there no
other MTI protocol exchanges in OpenID Connect?

Thanks,
prateek



> 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 <[e-mail] <mailto:[e-mail]>>
>
>     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 <[e-mail]
>     <mailto:[e-mail]>> wrote:
>
>>     Forgot reply all.
>>
>>     Phil
>>
>>     Begin forwarded message:
>>
>>>     *From:* Phil Hunt <[e-mail]
>>>     <mailto:[e-mail]>>
>>>     *Date:* 30 July, 2013 17:25:46 GMT+02:00
>>>     *To:* "Richer, Justin P." <[e-mail]
>>>     <mailto:[e-mail]>>
>>>     *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." <[e-mail]
>>>     <mailto:[e-mail]>> 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 <[e-mail]
>>>>     <mailto:[e-mail]>>
>>>>      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."
>>>>>     <[e-mail] <mailto:[e-mail]>> 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 <[e-mail]
>>>>>>     <mailto:[e-mail]>> 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 <http://www.independentid.com/>
>>>>>>>     [e-mail] <mailto:[e-mail]>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>     Begin forwarded message:
>>>>>>>
>>>>>>>>     *From: *[e-mail]
>>>>>>>>     <mailto:[e-mail]>
>>>>>>>>     *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 <[e-mail]
>>>>>>>>     <mailto:[e-mail]>>, Phil Hunt
>>>>>>>>     <[e-mail] <mailto:[e-mail]>>, 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 <http://tools.ietf.org/>.
>>>>>>>>
>>>>>>>>     The IETF Secretariat
>>>>>>>>
>>>>>>>
>>>>>>>     _______________________________________________
>>>>>>>     OAuth mailing list
>>>>>>>     [e-mail] <mailto:[e-mail]>
>>>>>>>     https://www.ietf.org/mailman/listinfo/oauth
>>>>>>
>>>>
>>     _______________________________________________
>>     OAuth mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/oauth
>
>
>     _______________________________________________
>     OAuth mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> -- 
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth