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

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