Re: [OAUTH-WG] Need for Extending OAuth with AuthN (was Re: Fwd: New Version Notification for draft-hunt-oauth-v2-user-a4c-00.txt)

[Nat Sakimura <[e-mail]>]

Like Bill says, it can just be a profile of OpenID Connect.
IETF specs already references OpenID Foundation specs.
It should not be a problem.
I do not think we want to folk.


2013/8/1 Anthony Nadalin <[e-mail]>

>  I believe it beneficial to have a common format and common values, and 1
> way to handle the format and values. I believe that having this in oauth is
> beneficial, I believe that it would also be beneficial for OpenID if this
> were in oauth. There are cases for signed and unsigned formats. ****
>
> ** **
>
> *From:* Richer, Justin P. [mailto:[e-mail]]
> *Sent:* Thursday, August 1, 2013 7:15 AM
> *To:* Nat Sakimura
> *Cc:* Anthony Nadalin; Bill Mills; Prateek Mishra; [e-mail] WG
>
> *Subject:* Re: [OAUTH-WG] Need for Extending OAuth with AuthN (was Re:
> Fwd: New Version Notification for draft-hunt-oauth-v2-user-a4c-00.txt)****
>
>  ** **
>
> Also, it's (optionally) a token in the proposed document we're discussing
> (§2.4.1), which means there are two ways to parse the same information.
> OIDC uses JWTs for everything, signed and unsigned. This means that OIDC is
> actually simpler from an implementation perspective, wouldn't you say?
> Instead of having two parsers, you have one to cover both cases.  ****
>
> ** **
>
> (And given your tendency to throw signed assertions at every problem, I
> would have thought that you'd prefer this anyway.) ****
>
> ** **
>
>  -- Justin****
>
> ** **
>
> On Aug 1, 2013, at 9:40 AM, Nat Sakimura <[e-mail]>****
>
>  wrote:****
>
>
>
> ****
>
>  Yes, it is a Token. ****
>
> No, it does not have to be signed. ****
>
> ** **
>
> As to be a token or not to be a token question, it has been discussed in
> the WG before, and if I remember correctly,  Microsoft argued for token
> saying that it is just base64 decoding and I lost there.  ****
>
> Nat****
>
>
> On Aug 1, 2013, at 14:24, Anthony Nadalin <[e-mail]> wrote:**
> **
>
> You can’t do this, first openid uses a token and second it’s signed, third
> there is no specification to just return a authentication JSON structure**
> **
>
>  ****
>
> *From:* Richer, Justin P. [mailto:[e-mail] <[e-mail]>]
> *Sent:* Thursday, August 1, 2013 5:15 AM
> *To:* Anthony Nadalin
> *Cc:* Bill Mills; Prateek Mishra; Nat Sakimura; [e-mail] WG
> *Subject:* Re: [OAUTH-WG] Need for Extending OAuth with AuthN (was Re:
> Fwd: New Version Notification for draft-hunt-oauth-v2-user-a4c-00.txt)****
>
>  ****
>
> Tony, you can already return the authn result from the token request (we
> discussed this specifically in May as I recall). That's what the "idtoken"
> and "code idtoken" responses are for in OpenID Connect. The proposed draft
> is nearly a duplicate of the core functionality of OIDC. ****
>
>  ****
>
>  -- Justin****
>
>  ****
>
> On Aug 1, 2013, at 7:31 AM, Anthony Nadalin <[e-mail]>****
>
>  wrote:****
>
> ** **
>
>  The proposal does not duplicate what OpenID does, there is clear benefit
> for returning an authentication result in the token request result. This is
> being proposed as optional JSON structure.****
>
>  ****
>
> *From:* [e-mail] [mailto:[e-mail]] *On Behalf
> Of *Bill Mills
> *Sent:* Wednesday, July 31, 2013 2:50 PM
> *To:* Prateek Mishra; Nat Sakimura
> *Cc:* [e-mail] WG
> *Subject:* Re: [OAUTH-WG] Need for Extending OAuth with AuthN (was Re:
> Fwd: New Version Notification for draft-hunt-oauth-v2-user-a4c-00.txt)****
>
>  ****
>
> Rather than extending OAuth for something OpenID already does...  why
> don't we get a simple informational example doc to show how to implement
> the most basic OpenID service, which is the same functionality on a
> standard that's already written?****
>
>  ****
>
> This is sounding more and mor elike a documentation problem.****
>
>  ****
>    ------------------------------
>
> *From:* Prateek Mishra <[e-mail]>
> *To:* Nat Sakimura <[e-mail]>
> *Cc:* "[e-mail] WG" <[e-mail]>
> *Sent:* Wednesday, July 31, 2013 2:38 PM
> *Subject:* [OAUTH-WG] Need for Extending OAuth with AuthN (was Re: Fwd:
> New Version Notification for draft-hunt-oauth-v2-user-a4c-00.txt)****
>
>  ****
>
> Nat -
>
> thanks for the detailed response. I did review the links you sent out but
> it remained unclear to me which
> features are MTI and which are not. For example, there is nothing in the
> Basic Client Profile that suggests
> that Section 2.3 is optional. I also could not find any definition for "
> non-dynamic OpenID Connect Server".
>
> I dont think there is a need to duplicate portions of the draft
> specification text in a new document. One solution
> that was used in SAML 2.0 was to define a conformance document which
> described several different
> operational modes and explained how only a small set of features needed to
> be implemented in certain modes.
>
> http://docs.oasis-open.org/security/saml/v2.0/saml-conformance-2.0-os.pdf
>
> There are probably other smarter ways to achieve the same effect.
>
> Given this situation, I do think its a reasonable task for the OAuth
> community to consider the need for
> a minimal extension to OAuth that accommodates authentication. The
> community should be made aware that
> RFC 6749 is being misused for federated authentication, as explained in  -
>
>
>
> http://www.independentid.com/2013/07/simple-authentication-for-oauth-2-what.html
>
>
> and that there doesn't appear to be a simple solution that is currently
> available. It would be great if it turned
> out that OpenID Connect offered such a solution but that isn't clear to me.
>
> Thx,
> prateek****
>
>  ****
>
>   ****
>
> Inline: ****
>
> 2013/7/31 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?****
>
>    ****
>
> Actually, it is not a single spec, that the Standard is referencing
> others. ****
>
> The Standard is kind of cluttered because it has 6 response types and
> three request types in it. ****
>
> I suppose it would be much easier for the readers to split them into
> coherent pieces, though that means duplicate texts. ****
>
>  ****
>
> The easiest approach here is to read the Basic Client Profile.
> http://openid.net/specs/openid-connect-basic-1_0-28.html****
>
> Then, read OAuth 2.0 Multiple Response Type Encoding Practices
> http://openid.net/specs/oauth-v2-multiple-response-types-1_0-08.html . ***
> *
>
>  ****
>
>
> 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?****
>
>    ****
>
> Yes, for a non-dynamic OpenID Connect Server. ****
>
>  ****
>
> Nat****
>
>   ****
>
>
> 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]>****
>
>  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 attools.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****
>
>
>
> ****
>
> _______________________________________________****
>
> OAuth mailing list****
>
> [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
>
> ****
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth****
>
>   ****
>
>   ** **
>



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