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

[Nat Sakimura <[e-mail]>]

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]>

> 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]> wrote:
>
> Forgot reply all.
>
> Phil
>
> Begin forwarded message:
>
> *From:* Phil Hunt <[e-mail]>
> *Date:* 30 July, 2013 17:25:46 GMT+02:00
> *To:* "Richer, Justin P." <[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]> 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]>
>  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]> 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]> 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
>  [e-mail]
>
>
>
>
>
> Begin forwarded message:
>
>  *From: *[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]>, Phil Hunt <[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.
>
> The IETF Secretariat
>
>
>  _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>  _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en