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)

From: Anthony Nadalin <[email-masked]>
Date: Thu, 1 Aug 2013 11:31:18 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Bill Mills
Sent: Wednesday, July 31, 2013 2:50 PM
To: Prateek Mishra; Nat Sakimura
Cc: [email-masked] 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 <[email-masked]<mailto:[email-masked]>>
To: Nat Sakimura <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked] WG<mailto:[email-masked]%20WG>" <[email-masked]<mailto:[email-masked]>>
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 <[email-masked]<mailto:[email-masked]>>
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 <[email-masked]<mailto:[email-masked]>>
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 <[email-masked]<mailto:[email-masked]>> wrote:

Forgot reply all.

Phil

Begin forwarded message:
From: Phil Hunt <[email-masked]<mailto:[email-masked]>>
Date: 30 July, 2013 17:25:46 GMT+02:00
To: "Richer, Justin P." <[email-masked]<mailto:[email-masked]>>
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." <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>>
 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." <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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/>
[email-masked]<mailto:[email-masked]>

Begin forwarded message:

From: [email-masked]<mailto:[email-masked]>
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 <[email-masked]<mailto:[email-masked]>>, Phil Hunt <[email-masked]<mailto:[email-masked]>>, 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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

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

_______________________________________________

OAuth mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/oauth

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

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: "Richer, Justin P." <[email-masked]>
Date: Thu, 1 Aug 2013 12:15:24 +0000

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 <[email-masked]<mailto:[email-masked]>>
 wrote:

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Bill Mills
Sent: Wednesday, July 31, 2013 2:50 PM
To: Prateek Mishra; Nat Sakimura
Cc: [email-masked]<mailto:[email-masked]> 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)

Nat -

Thx,
prateek

Inline:

Nat

Thanks,
prateek

e.g.,

Nat

Justin is correct.

John B.

Forgot reply all.

Phil

Begin forwarded message:

Phil

 -- Justin

Phil

 -- Justin

Phil

@independentid

Begin forwarded message:

From:[email-masked]<mailto:[email-masked]>
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 <[email-masked]<mailto:[email-masked]>>, Phil Hunt <[email-masked]<mailto:[email-masked]>>, Phil Hunt <>

Abstract:

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<http://tools.ietf.org/>.

The IETF Secretariat

OAuth mailing list

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 1 Aug 2013 12:22:46 +0000

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:[email-masked]]
Sent: Thursday, August 1, 2013 5:15 AM
To: Anthony Nadalin
Cc: Bill Mills; Prateek Mishra; Nat Sakimura; [email-masked] 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)

 -- Justin

Nat -

Thx,
prateek

Inline:

Nat

Thanks,
prateek

e.g.,

Nat

Justin is correct.

John B.

Forgot reply all.

Phil

Begin forwarded message:

Phil

 -- Justin

Phil

 -- Justin

Phil

@independentid

Begin forwarded message:

Abstract:

The IETF Secretariat

OAuth mailing list

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 1 Aug 2013 15:40:34 +0200

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 <[email-masked]> 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:[email-masked] <[email-masked]>]
*Sent:* Thursday, August 1, 2013 5:15 AM
*To:* Anthony Nadalin
*Cc:* Bill Mills; Prateek Mishra; Nat Sakimura; [email-masked] 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 <[email-masked]>

 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:* [email-masked] [mailto:[email-masked]] *On Behalf Of
 *Bill Mills
*Sent:* Wednesday, July 31, 2013 2:50 PM
*To:* Prateek Mishra; Nat Sakimura
*Cc:* [email-masked] 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?

   ------------------------------

*From:* Prateek Mishra <[email-masked]>
*To:* Nat Sakimura <[email-masked]>
*Cc:* "[email-masked] WG" <[email-masked]>
*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.

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  -

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 <[email-masked]>

 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.

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

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?

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/>
".

It puzzles me why you need to create a draft with only minor variances in
parameter names.

 e.g.,

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 <[email-masked]>

 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 <[email-masked]> wrote:

   Forgot reply all.

Phil

Begin forwarded message:

 *From:* Phil Hunt <[email-masked]>
*Date:* 30 July, 2013 17:25:46 GMT+02:00
*To:* "Richer, Justin P." <[email-masked]>
*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." <[email-masked]> 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.

 - Not fall over with other parameters that you don't support (display,
prompt, etc).

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 <[email-masked]>

 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.

Phil

On 2013-07-30, at 16:46, "Richer, Justin P." <[email-masked]> 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 <[email-masked]> 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.

Phil

@independentid

www.independentid.com

[email-masked]

Begin forwarded message:

   *From:[email-masked]

*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 <[email-masked]>, Phil Hunt <[email-masked]>, Phil
Hunt <>

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:

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

[email-masked]

[email-masked]

[email-masked]

-- 
Nat Sakimura (=nat)

OAuth mailing list

[email-masked]

-- 
Nat Sakimura (=nat)

[email-masked]

[email-masked]

---

From: "Richer, Justin P." <[email-masked]>
Date: Thu, 1 Aug 2013 14:14:54 +0000

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 <[email-masked]<mailto:[email-masked]>>
 wrote:

Yes, it is a Token.

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 <[email-masked]<mailto:[email-masked]>> 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:[email-masked]]
Sent: Thursday, August 1, 2013 5:15 AM
To: Anthony Nadalin
Cc: Bill Mills; Prateek Mishra; Nat Sakimura; [email-masked]<mailto:[email-masked]> 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)

 -- Justin

From: [email-masked]<mailto:[email-masked]> [mailto:oauth-<mailto:oauth->[email-masked]<mailto:[email-masked]>] On Behalf Of Bill Mills

Nat -

Thx,
prateek

Inline:

Nat

Thanks,
prateek

e.g.,

Nat

Justin is correct.

John B.

Forgot reply all.

Phil

Begin forwarded message:

Phil

 -- Justin

Phil

 -- Justin

Phil

@independentid

Begin forwarded message:

Abstract:

The IETF Secretariat

OAuth mailing list

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 1 Aug 2013 14:24:44 +0000

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:[email-masked]]
Sent: Thursday, August 1, 2013 7:15 AM
To: Nat Sakimura
Cc: Anthony Nadalin; Bill Mills; Prateek Mishra; [email-masked] 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)

 -- Justin

Yes, it is a Token.

 -- Justin

Nat -

Thx,
prateek

Inline:

Nat

Thanks,
prateek

e.g.,

Nat

Justin is correct.

John B.

Forgot reply all.

Phil

Begin forwarded message:

Phil

 -- Justin

Phil

 -- Justin

Phil

@independentid

Begin forwarded message:

Abstract:

The IETF Secretariat

OAuth mailing list

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 01 Aug 2013 17:05:06 +0200

Hi Nat, 

I think your are going in the right direction. Here are my
comments: 

- Authentication and attribute providing can be treated
separately. I therefore would recommend you move the claim stuff into a
separate specification, which includes standard claims, respective scope
values, user info endpoint and the claims parameter. This would leave
the base specification a small but reasonable extension to OAuth to
handle authentication properly. Everyone interested in claims can
implemented the complementary claims spec. Service provider wishing to
use other interfaces for claim providing can do that. I would not care.

- Use normativ language only to ensure proper implementation of the
protocol, e.g. with respect to security, not for MTI requirements. 

As
an example: "id tokens must be signed when sent via the user agent, they
may be signed when issued at the token endpoint" 

- I would recommend
to handle MTI in a separate document. Do not clutter the base spec with
MTI stuff, such as 

"OpenID Providers that are not Self-Issued OPs MUST
support this "response_type"." 

First, you are forward referencing to
concepts introduced in other documents. Moreover, there are so many
different scenarios I can think of where Connect could be used. They
have rather different requirements, so having a document with different
profile definitions is better suited (IMHO). A good starting point is
section 13, where the definition of open and closed systems and
respective MTIs is given. 

- Omit duplication of OAuth text. For
example, there is another description of the state parameter or there is
this statement: "In OpenID Connect, this communication MUST be over
TLS." As far as I remember, the same holds true for plain OAuth. 

-
3.2. Server Processings - it is the discretion of the server when the id
token is actually created. So don't make this part of the normative
text. 

- I would recommend to move "3.2.1. ID Token after the authz
response section". The description of the ID Token contents does not
help the reader at that point. 

- I would suggest to organize the doc
around the response types, i.e. describe the whole flow for code. Right
now it is distributed over 2 sections (incl. Section 4 "Tokens
Endpoint"). 

regards,
Torsten. 

Am 01.08.2013 06:27, schrieb Nat
Sakimura: 

> +1 
> 
> I am trying to figure out how we can streamline
the documentations. 
> Now that we are done with the implementer's draft
vote that diff is not that important any more as technical content is
determined and IPR is locked in, now is the time to do a major surgery
to fix the documentation clutter that is caused by its history. 
There are several proposals on the table right now in the AB/Connect WG
at OIDF. 
> 
> My proposal at the moment is to reorganize the doc into:

> 
> * OpenID Connect Core
> * OpenID Connect Discovery
> * OpenID
Connect Dynamic Registration
> * OpenID Connect Advanced Claims
Extension
> * OpenID Connect Advanced Client Authentication Methods
Extension
> * OpenID Connect Self-Issued Provider Extension
> * OpenID
Connect JSON Based Request Extension
> 
> Currently, I am experimenting
with whether keeping the different flows in the Core makes sense or it
is better to split them out. 
> 
> Here is the link to the Core draft I
am experimenting with: http://bit.ly/19yHvJB [14] 
> XML and HTML
versions are in the same repository as well. 
> Your input will be
most welcome. 
> 
> Nat 
> 
> 2013/8/1 Richer, Justin P.
<[email-masked]>
> 
>> +1 
>> 
>> On Jul 31, 2013, at 5:49 PM, Bill
Mills <[email-masked]> wrote: 
>>> 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? 
>>> -------------------------
>>> FROM: Prateek Mishra
<[email-masked]>
>>> TO: Nat Sakimura <[email-masked]>

>>> CC: "[email-masked] WG" <[email-masked]> 
>>> 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)
>>> 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
>>> 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.
[12]
>>> 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 
[13] 
>>> 
>>> 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.

>>>>> 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
>>>>> A) Can you direct me to a
single OpenID Connect draft specification document where steps 1 and 2
are described?
>>>> 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 [10] 
Then, read OAuth 2.0 Multiple Response Type Encoding Practices
http://openid.net/specs/oauth-v2-multiple-response-types-1_0-08.html
[11] . 
>>>> 
>>>>> B) If I implement steps 1 and 2, do I then have a
conformant OpenID Connect implementation? Are there no 
>>>> Thanks,
px solid; margin-left:5px; width:100%"> 
>>>>> I have written a short
blog post titled "Write an OpenID Connect server in three simple steps
[8]". 
>>>>> It puzzles me why you need to create a draft
with only minor variances in parameter names. 

alv instead of acr 
>>>>> If you change those
parameter names, you will have a conformant profile of OpenID Connect.

>>>>> 
>>>>> Nat 
>>>>> 
>>>>> 2013/7/31 John Bradley
<[email-masked]>
>>>>> 
>>>>>> 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. 

>>>>>>> Forgot reply
all.
>>>>>>> Begin forwarded
message:
>>>>>>>> FROM: Phil Hunt
<[email-masked]>
>>>>>>>> DATE: 30 July, 2013 17:25:46
GMT+02:00
>>>>>>>> TO: "Richer, Justin P." <[email-masked]>
>>>>>>>>
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. 

>>>>>>>>> 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. 
>>>>>>>>> - Not fall over with other parameters that you don't
support (display, prompt, etc). 
http://openid.net/specs/openid-connect-messages-1_0.html#ServerMTI [7]

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

>>>>>>>>> On Jul 30, 2013,
at 10:54 AM, Phil Hunt <[email-masked]> 

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

>>>>>>>>>>> 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 
>>>>>>>>>>>> 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. 
@independentid 
>>>>>>>>>>>> www.independentid.com [5]
[email-masked]

>>>>>>>>>>>>> FROM:
[email-masked]
>>>>>>>>>>>>> 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 <[email-masked]>, Phil Hunt <[email-masked]>, Phil Hunt
<>
>>>>>>>>>>>>> IETF
repository.
>>>>>>>>>>>>> Creation
date: 2013-07-29
[1]
[2]
>>>>>>>>>>>>> Htmlized:
http://tools.ietf.org/html/draft-hunt-oauth-v2-user-a4c-00
[3]
>>>>>>>>>>>>> This
specification defines a new OAuth2 endpoint that enables
user
>>>>>>>>>>>>> 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 [4].
>>>>>>>>>>>>> The IETF
Secretariat
>>>>>>>>>>>> OAuth
mailing list
>>>>>>>>>>>> [email-masked]
https://www.ietf.org/mailman/listinfo/oauth [6]
>>>>>>> OAuth mailing
list
>>>>>>> [email-masked]
https://www.ietf.org/mailman/listinfo/oauth [6]
>>>>>> OAuth mailing
list
>>>>>> [email-masked]
https://www.ietf.org/mailman/listinfo/oauth [6]
Nat Sakimura (=nat) 
>>>>> Chairman, OpenID Foundation
http://nat.sakimura.org/ [9]
>>>>> OAuth mailing
list
>>>>> [email-masked]
https://www.ietf.org/mailman/listinfo/oauth [6]
Nat Sakimura (=nat) 
>>>>> h
imura.org/
>>> OAuth mailing
list
>>> https://www.ietf.org/mailman/listinfo/oauth
[6]
>>> OAuth
mailing list
>>> [email-masked]
https://www.ietf.org/mailman/listinfo/oauth [6]
> Nat Sakimura
(=nat) 
> http://nat.sakimura.org/ [9]
>
@_nat_en 
> OAuth
mailing list
> [email-masked]
https://www.ietf.org/mailman/listinfo/oauth [6]

Links:
------
[1]
http://www.ietf.org/internet-drafts/draft-hunt-oauth-v2-user-a4c-00.txt
[2]
http://datatracker.ietf.org/doc/draft-hunt-oauth-v2-user-a4c
[3]
http://tools.ietf.org/html/draft-hunt-oauth-v2-user-a4c-00
[4]
http://tools.ietf.org/
[5] http://www.independentid.com/
[6]
https://www.ietf.org/mailman/listinfo/oauth
[7]
http://openid.net/specs/openid-connect-messages-1_0.html#ServerMTI
[8]
http://nat.sakimura.org/2013/07/28/write-openid-connect-server-in-three-simple-steps/
[9]
http://nat.sakimura.org/
[10]
http://openid.net/specs/openid-connect-basic-1_0-28.html
[11]
http://openid.net/specs/oauth-v2-multiple-response-types-1_0-08.html
[12]
http://docs.oasis-open.org/security/saml/v2.0/saml-conformance-2.0-os.pdf
[13]
http://www.independentid.com/2013/07/simple-authentication-for-oauth-2-what.html
[14]
http://bit.ly/19yHvJB

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 1 Aug 2013 18:07:45 +0200

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 <[email-masked]>

>  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:[email-masked]]
> *Sent:* Thursday, August 1, 2013 7:15 AM
> *To:* Nat Sakimura
> *Cc:* Anthony Nadalin; Bill Mills; Prateek Mishra; [email-masked] 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 <[email-masked]>****
>
>  wrote:****
>
>
>
> ****
>
>  Yes, it is a Token. ****
>
> No, it does not have to be signed. ****
>
> ** **
>
> saying that it is just base64 decoding and I lost there.  ****
>
> Nat****
>
>
> On Aug 1, 2013, at 14:24, Anthony Nadalin <[email-masked]> 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**
> **
>
>  ****
>
> *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)****
>
>  ****
>
> is nearly a duplicate of the core functionality of OIDC. ****
>
>  ****
>
>  -- Justin****
>
>  ****
>
> On Aug 1, 2013, at 7:31 AM, Anthony Nadalin <[email-masked]>****
>
>  wrote:****
>
> ** **
>
> being proposed as optional JSON structure.****
>
>  ****
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Bill Mills
> *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.****
>
>  ****
> *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 -
>
> prateek****
>  ****
>   ****
> Inline: ****
> 2013/7/31 Prateek Mishra <[email-masked]>****
>
>  Nat -
>
> 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. ****
>
> coherent pieces, though that means duplicate texts. ****
>
>  ****
>
> http://openid.net/specs/openid-connect-basic-1_0-28.html****
>
> http://openid.net/specs/oauth-v2-multiple-response-types-1_0-08.html . ***
> *
>
>  ****
>
>
> 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. ****
>
>  ****
>
> parameter names. ****
>  ****
>  e.g., ****
> session instead of id_token****
>
> lat instead of iat****
>
> alv instead of acr****
>
> etc. ****
>
>    ****
>
> OpenID Connect. ****
>  ****
> Nat****
>  ****
> 2013/7/31 John Bradley <[email-masked]>****
>
> deployment discovery, registration, userifo are all optional.****
>
>  ****
>
> 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 <[email-masked]> wrote:****
>
>
>
> ****
>
>   Forgot reply all.
>
> Phil****
>
>
> Begin forwarded message:****
>
> draft-hunt-oauth-v2-user-a4c-00.txt*****
>
> Phil****
> On 2013-07-30, at 17:17, "Richer, Justin P." <[email-masked]> wrote:***
> *
>
> folks using OAuth for authentication have also implemented. Namely:****
>
>  ****
>
> equivalent, you're asking for all kinds of token injection problems.****
>
>  - Session management requests (max auth age, auth time)****
>
> 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
> SCIM for this, too, and that's fine.****
>
>  ****
>
>  -- Justin****
>
>  ****
>
> On Jul 30, 2013, at 10:54 AM, Phil Hunt <[email-masked]>****
>
>  wrote:****
>
>
>
> ****
>
> far down the road.****
>  ****
> 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." <[email-masked]> 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
> 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
> for other services if your AS/IdP protects multiple things.****
>
>  ****
>
> do anything different (apart from syntax changes)?****
>
>  ****
>
>  -- Justin****
>
>  ****
>
> On Jul 29, 2013, at 4:14 AM, Phil Hunt <[email-masked]> wrote:****
>
>
>
> ****
>
> Clients using OAuth to authenticate users.****
>
>  ****
>
> 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).****
>
>  ****
>
>  I've tried to make it as compatible as possible with OIDC.****
>
>  ****
>
> the next re-chartering.****
>
>  ****
>
> Happy to answer questions and discuss. ****
>
>  ****
>
> Phil****
>
>  ****
>
> @independentid****
>
> www.independentid.com****
>
> [email-masked]****
>
>  ****
>
>
>
> ****
>
>  ****
>
> Begin forwarded message:****
>
>
>
> ****
>
>  *From:[email-masked]****
>
> *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 <[email-masked]>, Phil Hunt <[email-masked]>,
> Phil Hunt <>****
>
>  ****
>
>
> The IETF Secretariat****
>    ****
> https://www.ietf.org/mailman/listinfo/oauth****
>
>    ****
>
>    ****
>
> https://www.ietf.org/mailman/listinfo/oauth****
>
>    ****
>
>
> https://www.ietf.org/mailman/listinfo/oauth****
>
>
>
> ****
>
>  ****
>
> --
> Nat Sakimura (=nat)****
>
> @_nat_en****
> ****
> _______________________________________________****
>
> OAuth mailing list****
>
> [email-masked]****
>
> https://www.ietf.org/mailman/listinfo/oauth****
>
>    ****
>
>
>
> ****
>
>  ****
>
> --
> Nat Sakimura (=nat)****
>
> @_nat_en****
>   ****
> ****
> https://www.ietf.org/mailman/listinfo/oauth****
>
>   ****
>
>   ** **
>

---

From: Phil Hunt <[email-masked]>
Date: Fri, 2 Aug 2013 04:56:57 +0200

OpenId specs can depend on oAuth. Having OAuth depend on OpenId is not appropriate here. 

Phil

On 2013-08-01, at 18:07, Nat Sakimura <[email-masked]> wrote:

>> On Aug 1, 2013, at 9:40 AM, Nat Sakimura <[email-masked]>
>> 
>>  wrote:
>> 
>> 
>> 
>> 
>> Yes, it is a Token. 
>> 
>> From: Prateek Mishra <[email-masked]>
>> To: Nat Sakimura <[email-masked]> 
>> Cc: "[email-masked] WG" <[email-masked]> 
>> I have written a short blog post titled "Write an OpenID Connect server in three simple steps". 
>> 
>>  
>> 
>> From: Phil Hunt <[email-masked]>
>> To: "Richer, Justin P." <[email-masked]>
>> From:[email-masked]
>> 
>> To:Phil Hunt <[email-masked]>, Phil Hunt <[email-masked]>, Phil Hunt <>
>> 
>>  
>> 
>>

---

From: Mike Jones <[email-masked]>
Date: Fri, 2 Aug 2013 04:02:06 +0000

I agree that this write-up wouldn’t be written in a manner that was dependent upon the OpenID specs.  It would be written in a stand-alone manner.  However, I agree with what Tony said that having common format and values is the key.  Then whether people are implementing to the additional OAuth spec or to the OpenID Connect specs, their code would be compatible with both.

                                             -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Thursday, August 01, 2013 7:57 PM
To: Nat Sakimura
Cc: [email-masked] 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)

Phil

On 2013-08-01, at 18:07, Nat Sakimura <[email-masked]<mailto:[email-masked]>> wrote:

2013/8/1 Anthony Nadalin <[email-masked]<mailto:[email-masked]>>
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:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, August 1, 2013 7:15 AM
To: Nat Sakimura
Cc: Anthony Nadalin; Bill Mills; Prateek Mishra; [email-masked]<mailto:[email-masked]> WG

 -- Justin

Yes, it is a Token.

 -- Justin

Nat -

Thx,
prateek

Inline:

Nat

Thanks,
prateek

e.g.,

Nat

Justin is correct.

John B.

Forgot reply all.

Phil

Begin forwarded message:

Phil

 -- Justin

Phil

 -- Justin

Phil

@independentid

Begin forwarded message:

Abstract:

The IETF Secretariat

OAuth mailing list

---

From: Phil Hunt <[email-masked]>
Date: Fri, 2 Aug 2013 06:08:05 +0200

+1

Phil

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 2 Aug 2013 06:34:37 +0200

Not necessarily. Why would it be inappropriate?

I call it NIH syndrome.
Respecting the work which is done outside is a good thing.
Just taking the content and taking a credit for it is a bad practice.

Forking is also bad.

2013/8/2 Phil Hunt <[email-masked]>

>>  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. ****
>>
>> ** **
>>
>> On Aug 1, 2013, at 14:24, Anthony Nadalin <[email-masked]> wrote:*
>> ***
>>
>> structure****
>>  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:* [email-masked] [mailto:[email-masked]] *On
>> Behalf Of *Bill Mills
>> http://openid.net/specs/oauth-v2-multiple-response-types-1_0-08.html . **
>> **
>>
>>  ****
>>
>>
>> If you change those parameter names, you will have a conformant profile
>> of OpenID Connect. ****
>>
>>  ****
>>
>> Nat****
>>
>>  ****
>>
>> On 2013-07-30, at 17:17, "Richer, Justin P." <[email-masked]> wrote:**
>> **
>>
>> On 2013-07-30, at 16:46, "Richer, Justin P." <[email-masked]> wrote:**
>> **
>>
>>  FYI.  I have been noticing a substantial number of sites acting as
>> OAuth Clients using OAuth to authenticate users.****
>>
>>  ****
>>
>> *Subject: New Version Notification for

---

From: Bill Mills <[email-masked]>
Date: Thu, 1 Aug 2013 21:43:45 -0700 (PDT)

Circular references are not my favorite.

________________________________
 From: Nat Sakimura <[email-masked]>
To: Phil Hunt <[email-masked]> 
Cc: "[email-masked] WG" <[email-masked]> 
Sent: Thursday, August 1, 2013 9:34 PM
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)

I call it NIH syndrome. 

Forking is also bad. 

>>>From:Richer, Justin P. [mailto:[email-masked]] 
>>>>>From:Richer, Justin P. [mailto:[email-masked]]

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 2 Aug 2013 06:52:52 +0200

It is not a circular reference.
They are layered.
Profile referencing an extension sepc, which references a framework spec is
perfectly fine.
In fact, it should be that way.

It is just that the middle section in this case was worked out at an
outside forum.
Suppose it was worked in at OAuth WG and it was called OAuth Authentication
Extension.
And let us call what Phil is proposing as OAuth Authentication Extension
Basic Profile.

Then would it be a problem for the Basic Profile to reference the Authn
Extension, which in turn refences the RFC6749? Do we call it circular?

Of course not.

In this case, it is only that the "OAuth Authentication Extension" is
called "OpenID Connect".

2013/8/2 Bill Mills <[email-masked]>

>  *From:* Nat Sakimura <[email-masked]>
> *To:* Phil Hunt <[email-masked]>
> *Sent:* Thursday, August 1, 2013 9:34 PM
>
> Fwd: New Version Notification for draft-hunt-oauth-v2-user-a4c-00.txt)
>
>    It puzzles me why you need to create a draft with only minor variances
> in parameter names. ****
>     ****
>
>  e.g., ****
>    If you change those parameter names, you will have a conformant
> profile of OpenID Connect. ****
>     ****
>    Nat****
>     ****
>    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.****
>    ****
>     - 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
>    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. ****
>     ****
>    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
>    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****
>     ****
>    For now, I've just posted to keep track of the issue so we can address
> at the next re-chartering.****
>     ****

---

From: Phil Hunt <[email-masked]>
Date: Fri, 2 Aug 2013 07:01:32 +0200

Yes. Forking is bad. This is not a fork. 

It isn't like OIDF membership hasn't been aware of the issue and hasn't had time to respond (over a year now). The clear message was Connect is too far along to consider changes.

I brought the issue to the IETF because there is inappropriate use of oauth in the wild. The draft submitted discusses the issue an describes a possible simple fix.

The WG has a wide range of choices to make. One of which is to refer to OpenId Foundation. Another might be an errata to the security considerations. The first decision is to put it on the next charter.  

I think you are 'jumping the gun' here. 

Phil

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 2 Aug 2013 07:26:12 +0200

> It isn't like OIDF membership hasn't been aware of the issue and hasn't
> had time to respond (over a year now). The clear message was Connect is too
> far along to consider changes.
>

You are grossly misrepresenting it here.  You did not sign the IPR
agreement despite OIDF has done everything we could do to help you guys
out. We spent a lot of time / effort / legal fee to accommodate your
request but you have not signed the IPR agreement to date.

OIDF process mandates that the contributors signs the agreement before
being able to contribute anything to the WG. Unless you sign it, we cannot
take up the comment to avoid the IPR contamination. As the result, the
ticket was never created. If you have singed the IPR agreement and made a
comment, I am very sure that ticket was created and dealt with. You could
do it until couple of weeks ago. We had 45-days public review period. Did
you comment in there? Bunch of comments came in and we are accommodating
them.

Also, I have to point out that to join the OIDF WG, you do not have to be
an OIDF member. The only requirement is that you commit to the IPR
agreement, that you will not go after the implementers for your Patents
etc. for the implementation of the spec., that open source developers do
not have to worry about being sued.

As far as the Connect spec modification possibility is concerned, for
editorial changes, we can still do without a problem. We may also still do
some non-breaking changes if it is deemed necessary.
FYI, the Connect WG is contemplating the documentation structure change as
well, so that you know.

> I brought the issue to the IETF because there is inappropriate use of
> oauth in the wild. The draft submitted discusses the issue an describes a
> possible simple fix.
>
> The WG has a wide range of choices to make. One of which is to refer to
> OpenId Foundation. Another might be an errata to the security
> considerations. The first decision is to put it on the next charter.
>

Yes. My top priority here is not to fork. At least align the claim names.
Just saying alv instead of acr etc. does not make sense at all.

> I think you are 'jumping the gun' here.

I do hope that developers do not do 'jumping the gun', using slightly
different claim names.