Subject: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 05 Jun 2014 09:44:35 +0200

Hi Phil,

thanks for producing this document write-up. I have a somewhat basic
question regarding the document.

The id token contains the following mandatory information:
 - sis: issuer
 - sub: subject
 - aud: audience
 - iat: issued at
 - exp: expiry
 - auth_time: time when the end user was authenticated

An access token (when encoded as a JWT) may contain all these fields
except the auth_time (since auth_time is not defined in the JWT spec).

Given that your proposal actually does not define the authentication
protocol to be used between the resource owner/end user and the
authorisation server I am wondering whether it would be possible to just
add the auth_time parameter (and maybe some of the optional parameters)
to the access token. Then, you can skip the id token.

How do I come up with that question? In Kerberos, for example, the
above-listed information is carried within a single container (within
the ticket) and so I am curious to hear why we have to send the
information twice in OAuth (once in the access token, when the info is
passed per value, and again via the id token).

Maybe I missing something important here.

Ciao
Hannes

---

From: Phil Hunt <[email-masked]>
Date: Thu, 5 Jun 2014 08:54:08 -0700

You are correct. Just adding to access token would make a lot of devs happy and that certainly should be discussed. 

Two requirements issues:

1. A key use case is passing auth ctx only. An access token means asking for consent to access something. This causes many sites to loose new users. Authen only can be implicit consent. 

2.  Compatibility with OpenId ID Token and flows. 

3. There is a need to support re-auth and MFA/LOA negotiation. Eg web site would like to obtain a higher level of assurance for a higher risk action. 

The non-tech requirement is the soln must be received by client and service provider developers as easy to implement in addition to 6749 or even OAuth 1.1a. I mention it because devs feel this should be trivial.  Your suggestion of adding to access token certainly fits this. 

Phil

> On Jun 5, 2014, at 0:44, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi Phil,
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 5 Jun 2014 17:46:43 +0000

Hannes, the Access Token and ID Token do quite different things and have different structures and properties.  The Access Token is an opaque value that grants access to resources.  An ID Token is a non-opaque JWT security token that makes claims about the authentication that occurred.  You can have one without the other or you can have both, depending upon the use case.  Thus, trying to move information between them would be problematic in several regards.

Also, trying to overload the Access Token to convey authentication information has been demonstrated in practice to be fraught with peril, and has resulted in some of the most prominent security breaches related to the misuse of OAuth.

				-- Mike

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Thursday, June 05, 2014 8:54 AM
To: Hannes Tschofenig
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c

Two requirements issues:

Phil

> authorisation server I am wondering whether it would be possible to 
> just add the auth_time parameter (and maybe some of the optional 
> parameters) to the access token. Then, you can skip the id token.
> 

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

---

From: Bill Mills <[email-masked]>
Date: Thu, 5 Jun 2014 12:20:41 -0700 (PDT)

Can't agree more with the peril of overloading auth information into an access token.

On Thursday, June 5, 2014 11:05 AM, Mike Jones <[email-masked]> wrote:

                -- Mike

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Thursday, June 05, 2014 8:54 AM
To: Hannes Tschofenig
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c

Two requirements issues:

Phil

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 5 Jun 2014 21:39:34 +0200

+1

the access token is opaque to the client. That's great! Let's keep it that way.

> Am 05.06.2014 um 21:20 schrieb Bill Mills <[email-masked]>:
>

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 5 Jun 2014 19:42:12 +0000

It’s great but some ways but also very limiting if you are counting on certain requirements to be represented in the access token

From: OAuth [mailto:[email-masked]] On Behalf Of Torsten Lodderstedt
Sent: Thursday, June 5, 2014 12:40 PM
To: Bill Mills
Cc: Phil Hunt; [email-masked]
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c

+1

Am 05.06.2014 um 21:20 schrieb Bill Mills <[email-masked]<mailto:[email-masked]>>:
Can't agree more with the peril of overloading auth information into an access token.

On Thursday, June 5, 2014 11:05 AM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

                -- Mike

-----Original Message-----
From: OAuth [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Phil Hunt
Sent: Thursday, June 05, 2014 8:54 AM
To: Hannes Tschofenig
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c

Two requirements issues:

Phil

> On Jun 5, 2014, at 0:44, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi Phil,
>

_______________________________________________
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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 5 Jun 2014 21:45:15 +0200

Examples?

> Am 05.06.2014 um 21:42 schrieb Anthony Nadalin <[email-masked]>:
>

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 5 Jun 2014 19:47:04 +0000

Delegation

From: Torsten Lodderstedt [mailto:[email-masked]]
Sent: Thursday, June 5, 2014 12:45 PM
To: Anthony Nadalin
Cc: Bill Mills; Phil Hunt; [email-masked]
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c

Examples?

Am 05.06.2014 um 21:42 schrieb Anthony Nadalin <[email-masked]<mailto:[email-masked]>>:
It’s great but some ways but also very limiting if you are counting on certain requirements to be represented in the access token

From: OAuth [mailto:[email-masked]] On Behalf Of Torsten Lodderstedt
Sent: Thursday, June 5, 2014 12:40 PM
To: Bill Mills
Cc: Phil Hunt; [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c

+1

                -- Mike

-----Original Message-----
From: OAuth [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Phil Hunt
Sent: Thursday, June 05, 2014 8:54 AM
To: Hannes Tschofenig
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c

Two requirements issues:

Phil

---

From: Bill Mills <[email-masked]>
Date: Thu, 5 Jun 2014 12:52:39 -0700 (PDT)

If you need user info based on an access token the introspection endpoint is the right way to go.  Even so, there's issues with using an access token as an authenticator and this is a major reason why OpenID is the right way to go for authn.

On Thursday, June 5, 2014 12:42 PM, Anthony Nadalin <[email-masked]> wrote:

From:OAuth [mailto:[email-masked]] On Behalf Of Torsten Lodderstedt
Sent: Thursday, June 5, 2014 12:40 PM
To: Bill Mills
Cc: Phil Hunt; [email-masked]
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
 
+1

---

From: Phil Hunt <[email-masked]>
Date: Thu, 5 Jun 2014 13:00:58 -0700

A core issue for me is that authentication and access are two separate functions.  Some clients want authentication context only.  Some want access only, some want both.

If you combine both complexity ensues (such as loss of opaqueness, needing introspection, etc etc). 

Phil

[email-masked]

---

From: John Bradley <[email-masked]>
Date: Thu, 5 Jun 2014 16:11:50 -0400

Looking at the latest draft  http://tools.ietf.org/html/draft-hunt-oauth-v2-user-a4c-03 it is better.

As far as I can see he deltas from Connect Basic profile are:
1 A new response_type "code_id_token"  (I think the similarity to the "code id_token" response_type may cause some confusion but that can be sorted out.) 
2 a new request parameter "min_alv"  (I think min_alv="2" is isomorphic to acr_values="4 3 2" so having 2 ways to make the same request may not be ideal, but that can be debated.)

In Connect we probably would have added a way to get id_token only from the token endpoint but RFC6849 requires a access token be issued for a grant_type of authorization_code.

I think to be consistent with RFC6849 a new grant type needs to be defined.

In previous discussions returning a access token with no scopes was considered easier than trying to explain a OAuth flow with no access token. 
This needs discussion.

Other than that Mike has done a good job of reconciling a4c with Connect Basic profile.

This spec on it's own would not allow you to do any sort of scalable SSO, as the trust model is unspecified other than trusting the JWT based on the TLS cert of the token endpoint.
I think there needs to be some validation of issuer if there is more than one the client is dealing with. 

It is Shorter than Connect basic because it leaves out interoperating with multiple IdP and user attributes.

I don't hate it, but don't know that it adds much, other than possible confusion and future extensions that are incompatible with Connect.

It is however better than it was.

John B.

---

From: John Bradley <[email-masked]>
Date: Thu, 5 Jun 2014 16:19:09 -0400

Using structured access tokens to do delegation or convey other claims to the RS can and should be separate from the assertions delivered to the client.

The tokens will have different audiences and if using Proof of Possession different presenter key material.

Using one token for both things may work in the simplest use case but breaks a lot of things in OAuth.

John B.

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 12 Jun 2014 09:57:10 +0200

Hi Mike,

thanks for your quick response.

On 06/05/2014 07:46 PM, Mike Jones wrote:
> Hannes, the Access Token and ID Token do quite different things and
> have different structures and properties.  The Access Token is an
> opaque value that grants access to resources.  An ID Token is a
> non-opaque JWT security token that makes claims about the
> authentication that occurred.  You can have one without the other or
> you can have both, depending upon the use case.  Thus, trying to move
> information between them would be problematic in several regards.

Regarding the different structure between the access token and the ID
token: As I tried to explain with my example they two may carry almost
the same information (if the access token carries the information per
value and uses the JWT encoding).

Regarding the opaque nature: I think it is important to also add for
whom the tokens are opaque. From the text in the document the access
token and the ID token seem to be opaque for the client but they are not
opaque for the party generating them (=authorization server) and also
not opaque for the party consuming them (=resource server).

> 
> Also, trying to overload the Access Token to convey authentication
> information has been demonstrated in practice to be fraught with
> peril, and has resulted in some of the most prominent security
> breaches related to the misuse of OAuth.
The problems with the security breaches had nothing to do with the
encoding of the information in the token itself, which is what I am
referring to.

Ciao
Hannes

> 
> -- Mike
> 
> -----Original Message----- From: OAuth
> [mailto:[email-masked]] On Behalf Of Phil Hunt Sent:
> Thursday, June 05, 2014 8:54 AM To: Hannes Tschofenig Cc:
> [email-masked] Subject: Re: [OAUTH-WG] Question regarding
> draft-hunt-oauth-v2-user-a4c
> 
> You are correct. Just adding to access token would make a lot of devs
> happy and that certainly should be discussed.
> 
> Two requirements issues:
> 
> 1. A key use case is passing auth ctx only. An access token means
> asking for consent to access something. This causes many sites to
> loose new users. Authen only can be implicit consent.
> 
> 3. There is a need to support re-auth and MFA/LOA negotiation. Eg web
> site would like to obtain a higher level of assurance for a higher
> risk action.
> 
> The non-tech requirement is the soln must be received by client and
> service provider developers as easy to implement in addition to 6749
> or even OAuth 1.1a. I mention it because devs feel this should be
> trivial.  Your suggestion of adding to access token certainly fits
> this.
> 
> Phil
> 
>> thanks for producing this document write-up. I have a somewhat
>> basic question regarding the document.
>> 
>> The id token contains the following mandatory information: - sis:
>> issuer - sub: subject - aud: audience - iat: issued at - exp:
>> expiry - auth_time: time when the end user was authenticated
>> 
>> An access token (when encoded as a JWT) may contain all these
>> fields except the auth_time (since auth_time is not defined in the
>> JWT spec).
>> 
>> Given that your proposal actually does not define the
>> authentication protocol to be used between the resource owner/end
>> user and the authorisation server I am wondering whether it would
>> be possible to just add the auth_time parameter (and maybe some of
>> the optional parameters) to the access token. Then, you can skip
>> the id token.
>> 
>>  above-listed information is carried within a single container
>> (within the ticket) and so I am curious to hear why we have to send
>> the information twice in OAuth (once in the access token, when the
>> info is passed per value, and again via the id token).
>> 
>> Ciao Hannes
> _______________________________________________ OAuth mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 12 Jun 2014 10:03:23 +0200

> Can't agree more with the peril of overloading auth information into an

Explain that a bit more, Bill.

I think we should to provide a design rational so that a reader who has
not participated in the standardization process understands the spec.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 12 Jun 2014 10:04:55 +0200

Torsten,

nobody suggested that the access token would suddenly not be opaque to
the client.

The question therefore is whether the id token is not opaque to the
client. Is that the assumption?

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 12 Jun 2014 10:10:38 +0200

The token introspection is useful when you use an access token that is
just a reference (instead of passing the values around using a JWT).

Using token introspection on the access token to get the content of the
access token in addition to the ID token will still get you the same
data twice (at least in the way it is currently defined).

On 06/05/2014 09:52 PM, Bill Mills wrote:
> If you need user info based on an access token the introspection
> endpoint is the right way to go.  Even so, there's issues with using an
> access token as an authenticator and this is a major reason why OpenID
> is the right way to go for authn.

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 12 Jun 2014 10:14:09 +0200

Only a short note: We haven't standardized a delegation mechanism yet
and the proposals we had discussed in the past did not require the
client to understand the content of the access token even for delegation.

Having said that I would like to note that it still required the AS to
send additional information to the client. Other protocols that support
delegation, like Kerberos, have included the information in the same
ticket (just in the unencrypted part of the payload).

Ciao
Hannes

On 06/05/2014 10:19 PM, John Bradley wrote:
> Using structured access tokens to do delegation or convey other claims
> to the RS can and should be separate from the assertions delivered to
> the client.
> 
> The tokens will have different audiences and if using Proof of
> Possession different presenter key material.
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 12 Jun 2014 10:16:01 +0200

The argument about confusing draft-hunt-oauth-v2-user-a4c-03 with the
OpenID Connect work is indeed something to be careful about. Maybe this
could be addressed by more precisely capturing the differences in a
section of the document.

Ciao
Hannes

---

From: John Bradley <[email-masked]>
Date: Thu, 12 Jun 2014 09:25:00 -0400

The Id_token is audienced to the client.  It is not sent to a resource server.  In a4c there may be no access token or resource server. 

The id_token is not opaque to the client. 

John B. 

Sent from my iPhone

> On Jun 12, 2014, at 4:04 AM, Hannes Tschofenig <[email-masked]> wrote:
> 
> Torsten,
>

---

From: John Bradley <[email-masked]>
Date: Thu, 12 Jun 2014 09:30:32 -0400

The response from the token endpoint has multiple parameters.  

There is no reason to put information the client needs in the access token. 

That creates more problems than it solves. 

John B. 

Sent from my iPhone

> On Jun 12, 2014, at 4:14 AM, Hannes Tschofenig <[email-masked]> wrote:
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 12 Jun 2014 09:30:36 -0400

Right, and the original question in this part of the thread was "why 
bother with an ID token, why not just re-use the access token for both 
purposes?"

Torsten's response below was in answer to that -- merging these two 
would make the access token non-opaque to the client. This is 
undesirable for many reasons. We had this discussion years ago in the 
OIDC working group (several times) and came to the same conclusion there 
(several times).

Which goes to further the point that the A4C draft is simply re-hashing 
work that's already been covered by OIDC, often incompletely and missing 
key functionality required for interoperability and security, and adding 
nothing new or valuable to the conversation.

  -- Justin

---

From: Prateek Mishra <[email-masked]>
Date: Thu, 12 Jun 2014 09:39:44 -0700

+1 to Hannes comments.

---

From: Prateek Mishra <[email-masked]>
Date: Thu, 12 Jun 2014 09:49:32 -0700

The OpenID Connect 2.0 COre specification alone is 86 pages. It has 
received review from maybe a dozen engineers within the OpenID community.

The a4c draft proposal is 15 pages and will receive review from 100s of 
engineers within the world's most advanced standards body the IETF.

It's a no brainer which specification is likely to have more bugs, 
complexity and security holes.

> OIDC working group (several times) and came to the same conclusion 
> there (several times).
>
> Which goes to further the point that the A4C draft is simply 
> re-hashing work that's already been covered by OIDC, often 
> incompletely and missing key functionality required for 
> interoperability and security, and adding nothing new or valuable to 
> the conversation.
>
>  -- Justin
>
>>> On Jun 12, 2014, at 4:04 AM, Hannes Tschofenig<[email-masked]>  wrote:
>>>
>>> Torsten,
>>>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 12 Jun 2014 10:22:09 -0700

One of the use cases is to return only a token that is NOT an access token and is only an authentication assertion that is not opaque to the client.

A key concern is clients do not always want to ask users for consent to access their profiles or any other resource.  They just want authentication.

How many times do we see things like login with Yahoo, Twitter, Facebook and they apparently want access to too much information?  I’ve got lots of web site developers who don’t want that because it looses registrations as a significant percentage of users always refuse.  These developers  just want an authn ctx and the easy-sign-on benefits.

From this standpoint, having separate tokens makes sense.  One remains opaque to the client targeted for the resource server. The other is for the client.

You could have a new token type that can be dual-purpose and parseable to everyone, but I think that may end up being more confusing.  It would also mean impacts to resource servers to support a new non-opaque token type.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Bill Burke <[email-masked]>
Date: Thu, 12 Jun 2014 15:50:47 -0400

> received review from maybe a dozen engineers within the OpenID community.

The OpenID Connect spec is 86 pages because it pretty much rehashes the 
OAuth2 spec walking through each flow and how Open ID Connect expands on 
that flow.  A4c looks like a subset of this work minus some additional 
claims and, IMO, is incomplete compared to OIDC.

FWIW, add 5 Red Hat engineers to the "dozen" of reviewers.  We 
originally were creating our own oauth2 extension using JWT, but found 
that any feature we wanted to define already existed in OpenID Connect. 
  These guys have done great work.   Aren't many of you here authors of 
this spec and/or the same companies?!?  I think your energies are better 
focused on lobbying OIDC to join the IETF and this WG.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

---

From: Phil Hunt <[email-masked]>
Date: Thu, 12 Jun 2014 13:18:49 -0700

Phil

> On Jun 12, 2014, at 12:50, Bill Burke <[email-masked]> wrote:
> 
> 
> 
> The OpenID Connect spec is 86 pages because it pretty much rehashes the OAuth2 spec walking through each flow and how Open ID Connect expands on that flow.  A4c looks like a subset of this work minus some additional claims and, IMO, is incomplete compared to OIDC.
In what regards?

Much of oidc is out of scope for this requirement. 

It is a bit like saying an 18 wheeler is suitable for driving the kids to school. :-)
> 
> FWIW, add 5 Red Hat engineers to the "dozen" of reviewers.  We originally were creating our own oauth2 extension using JWT, but found that any feature we wanted to define already existed in OpenID Connect.  These guys have done great work.   Aren't many of you here authors of this spec and/or the same companies?!?  I think your energies are better focused on lobbying OIDC to join the IETF and this WG.

---

From: Hans Zandbelt <[email-masked]>
Date: Thu, 12 Jun 2014 22:38:09 +0200

+1, after implementing OIDC I will support the claim that any SSO 
protocol with a minimal set of required features smaller than OIDC is 
insecure and any protocol with similar features but with different 
parameter names is just creating confusion and will increase chances of 
non-interoperable and insecure implementations

Hans.

-- 
Hans Zandbelt              | Sr. Technical Architect
[email-masked] | Ping Identity

---

From: John Bradley <[email-masked]>
Date: Thu, 12 Jun 2014 17:18:40 -0400

All but a handful of OAuth WG participants participated in developing OpenID Connect.  

Yes some companies chose not to participate for whatever reasons and have not committed to the mutual non assert IPR agreement, and that is unfortunate, but not a reason to start again from scratch.

Changing the OIDF IPR policy of totally open specifications based on non asserts is also not a option.

I have made comments on the current draft of a4c.

I think a profile of Connect introducing a grant_type returning only an id_token would be simpler than trying to do this as a separate spec.
I do note that you can do effectively the same thing now by using a code response_type and a scope of openID.   This doesn't result in any extra user consent other than consenting to login to the RP the first time (though that consent can be given in advance out of band in a enterprise scenario.

When developing Connect we debated having a token endpoint response with only a id_token but decided that it was not in the spirit of being a OAuth 2 profile.   So we decided to return a access token even if the user info endpoint contains no claims other then sub.   People almost always want more claims as they roll out a real deployment.  It is easy to add them if you have designed to be able to talk to a RS.
OAuth without a RS is a touch not OAuth.

a4c also completely ignores modern development environments like node.js where the client is in the user agent, that OAuth 2 and Connect support.

By the time the OAuth WG is done with a4c it will likely be a similar size as Connect if it addresses the same use cases.  

I still don't see the problem with having a deployment profile of Connect that can meet 100% of the current stated use case for a4c. 

I expect that the people here involved in Connect will form there own opinions on comments regarding the number of participants and the quantity of the work and review.

Regards
John B.

On Jun 12, 2014, at 4:38 PM, Hans Zandbelt <[email-masked]> wrote:

> +1, after implementing OIDC I will support the claim that any SSO protocol with a minimal set of required features smaller than OIDC is insecure and any protocol with similar features but with different parameter names is just creating confusion and will increase chances of non-interoperable and insecure implementations
> 
> Hans.
>

---

From: Anil Saldhana <[email-masked]>
Date: Fri, 13 Jun 2014 09:21:21 -0500

> How many times do we see things like login with Yahoo, Twitter, Facebook and they apparently want access to too much information?  I’ve got lots of web site developers who don’t want that because i…
If the developers want just the authentication context and not the 
entire details about the user from providers such as Facebook, can we 
just not ask with an appropriate scope for the provider? Something like 
scope=username or scope=useremail. When the provider gives the data, 
then it is understood that there was authentication and some user consent.

---

From: Bill Burke <[email-masked]>
Date: Fri, 13 Jun 2014 10:24:59 -0400

On 6/13/2014 10:21 AM, Anil Saldhana wrote:
>> One of the use cases is to return only a token that is NOT an access
>> token and is only an authentication assertion that is not opaque to
>> the client.
>>
>> A key concern is clients do not always want to ask users for consent
>> to access their profiles or any other resource.  They just want
>> authentication.
>>
>> How many times do we see things like login with Yahoo, Twitter,
>> Facebook and they apparently want access to too much information?
>> I’ve got lots of web site developers who don’t want that because it
>> looses registrations as a significant percentage of users always
>> refuse.  These developers  just want an authn ctx and the easy-sign-on
>> benefits.

OpenID Connect already has this defined:

http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims

---

From: Anil Saldhana <[email-masked]>
Date: Fri, 13 Jun 2014 10:23:34 -0500

> http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims
Bill - thanks - I forgot about those. :-) Most of them come from the 
Open 1.0 world.

---

From: Prateek Mishra <[email-masked]>
Date: Fri, 13 Jun 2014 08:46:53 -0700

Thanks, Bill - I certainly appreciate the comment from an implementor 
who wasnt involved in the OIDC protocol design.

My understanding of the discussion around a4c is one of a minimalist 
extension to OAuth, not a full-featured one like OIDC.
One concern I have heard expressed is that OIDC is so large and full 
featured that most people just implement some
subset of their own choice. I believe this is the case with all the 
large consumer web sites.

I would welcome the publication of a minimalist draft from OIDC to the 
OAuth IETF. We have spent a lot of time lobbying for
this outcome! There is no question in my mind that the review within 
IETF would be more comprehensive and expose the work
to a larger community.

- prateek

> The OpenID Connect spec is 86 pages because it pretty much rehashes 
> the OAuth2 spec walking through each flow and how Open ID Connect 
> expands on that flow.  A4c looks like a subset of this work minus some 
> additional claims and, IMO, is incomplete compared to OIDC.
>
> that any feature we wanted to define already existed in OpenID 
> Connect.  These guys have done great work.   Aren't many of you here 
> authors of this spec and/or the same companies?!?  I think your 
> energies are better focused on lobbying OIDC to join the IETF and this 
> WG.
>
>

---

From: Bill Burke <[email-masked]>
Date: Fri, 13 Jun 2014 12:03:38 -0400

> Much of oidc is out of scope for this requirement.

What is in a4c that isn't already in OIDC?

> It is a bit like saying an 18 wheeler is suitable for driving the kids to school. :-)

I don't think this is true.  Most oidc oauth extensions are optional 
with the sole requirement that providers don't barf if you send them.

---

From: Bill Burke <[email-masked]>
Date: Fri, 13 Jun 2014 12:21:41 -0400

> IETF would be more comprehensive and expose the work

I don't think a minimalist draft of OIDC is needed as many of the 
extensions are optional.   Our implementation was already Oauth2/JWT 
based and it was really easy to meet the minimal requirements of OIDC core.

To create competing standards at IETF just because OIDC is not part of 
IETF, IMO, is a disservice to the community.

---

From: Prateek Mishra <[email-masked]>
Date: Fri, 13 Jun 2014 09:24:08 -0700

Excellent, now you have put your finger on the precise issue with OIDC - 
lots of optional extensions and shiny trinkets and lack of a clear 
definition of a core subset
for servers.

I realize its exciting for consultants, software and toolkit vendors to 
have that sort of optionality, but in practice, its NOT A GOOD THING in 
a protocol.

[quote]
> with the sole requirement that providers don't barf if you send them.
[\quote]

---

From: Anil Saldhana <[email-masked]>
Date: Fri, 13 Jun 2014 11:27:09 -0500

For me it boils down to this:
OAuth deals with Authorization.

Authentication needs to be outside its realm - whether it is OIDC, SAML 
or other protocols, it is fine.

The security community has just muddled up things for end users, 
implementors and adopters.

We need to start having clear cut separation in the standards.

On 06/13/2014 11:24 AM, Prateek Mishra wrote:
> Excellent, now you have put your finger on the precise issue with OIDC 
> - lots of optional extensions and shiny trinkets and lack of a clear 
> I realize its exciting for consultants, software and toolkit vendors 
> to have that sort of optionality, but in practice, its NOT A GOOD 
> THING in a protocol.
>
> [quote]
>>

---

From: Mike Jones <[email-masked]>
Date: Fri, 13 Jun 2014 16:27:21 +0000

Actually, there is a very clear definition of what the minimal Mandatory To Implement (MTI) in OpenID Connect is - it's right in the spec.  See the (quite short) sections:

    15.1.<http://openid.net/specs/openid-connect-core-1_0.html#ServerMTI>  Mandatory to Implement Features for All OpenID Providers
    15.2.<http://openid.net/specs/openid-connect-core-1_0.html#DynamicMTI>  Mandatory to Implement Features for Dynamic OpenID Providers

                                                            -- Mike

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Prateek Mishra
Sent: Friday, June 13, 2014 9:24 AM
To: Bill Burke; Phil Hunt
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c

Excellent, now you have put your finger on the precise issue with OIDC - lots of optional extensions and shiny trinkets and lack of a clear definition of a core subset for servers.

I realize its exciting for consultants, software and toolkit vendors to have that sort of optionality, but in practice, its NOT A GOOD THING in a protocol.

[quote]

>> It is a bit like saying an 18 wheeler is suitable for driving the

>> kids to school. :-)

[\quote]

OAuth mailing list

---

From: Prateek Mishra <[email-masked]>
Date: Fri, 13 Jun 2014 09:54:43 -0700

Mike -  when i see language like

[quote]
This list augments the set of features that are already listed elsewhere 
as being "REQUIRED" or are described with a "MUST", and so is not, by 
itself, a comprehensive set of implementation requirements for OPs.
[\quote]

in Section 15.1, I have to say this isn't a clear definition of what is 
MTI.

I guess someone could through comprehensive research determine exactly 
what might be meant by this section, but that doesn't meet the criteria 
of "very clear definition of MTI".

- prateek

- prateek

> Actually, there is a very clear definition of what the minimal 
> Mandatory To Implement (MTI) in OpenID Connect is - it's right in the 
> spec.  See the (quite short) sections:
>
> *15.1.* 
> <http://openid.net/specs/openid-connect-core-1_0.html#ServerMTI> 
> Mandatory to Implement Features for All OpenID Providers
> *15.2.* 
> <http://openid.net/specs/openid-connect-core-1_0.html#DynamicMTI> 
> Mandatory to Implement Features for Dynamic OpenID Providers
>
> -- Mike
>
> definition of a core subset for servers.
>
> [email-masked] <mailto:[email-masked]>
>

---

From: Bill Burke <[email-masked]>
Date: Fri, 13 Jun 2014 13:10:25 -0400

> definition of a core subset

OIDC is a very clear specification.  Your phrase "shiny trinkets" hints 
that there are a lot of silly features in OIDC.  I disagree with your 
assessment.  I just see features that I want to implement and are on our 
roadmap.  At the same time, I'm relieved that I can call myself an OIDC 
compliant implementation and put off implementing these features for a 
later date.

Also, you make it sound like OIDC is this big bloated specification.  I 
completely disagree with your assessment.  Personally I see OIDC as a 
specification driven by real-world requirements and experience.

> have that sort of optionality, but in practice, its NOT A GOOD THING in

I disagree.  If OIDC core was instead broken up into a set of smaller 
optional specifications, you would run the risk of having zero 
interoperability.  Maybe that is your end-goal, but it certainly isn't 
mine.  Most of the language around optional features states that "if you 
don't implement this, your implementation needs to handle it 
gracefully".  All *GOOD* things for a protocol.

But, IMO, there is no difference in having a complete, robust 
specification like OIDC that has a lot of optional parts from re-hashing 
OIDC at the IETF with a lot of optional specifications.  Other than 
causing confusion in the community, of course.

Let me further say that my experience as an OAuth 2.0 implementor was 
difficult as it was hard to put a finger on what exact OAuth 2 
extensions people were gravitating towards.  OIDC, for me at least, gave 
a much more complete direction for my project.

---

From: Phil Hunt <[email-masked]>
Date: Fri, 13 Jun 2014 10:10:48 -0700

I am going to address a few comments all together here:

1. John Bradley confirmed again yesterday, OIDC does not allow for authentication only as part of the normal code flow and decided intentionally not to address it.  So to say OIDC has a solution is confusing.

OIDC has the solution if you want to propagate profile information and authen information.  This means service providers have to implement much more code, and clients have to as well. For many there are customer abandonment and legal issues around sharing of too much PII information. They DO NOT want to have to ask for this information.

2. Regarding speculative future size: I  point out that the A4C draft is modelled exactly on the authorizaiton flow and has exactly the same security model. Therefore I would not expect any large increase in size, but rather the opposite. The number 1 challenge with this spec is not figuring out how to do this, but how to avoid scope creep into OIDC’s coverage.  I do NOT support scope creep into OIDC.  

We need a specific draft that addresses the issues of developers thinking 6749 is sufficient on its own.  I do NOT want to see stuff like browser based apps and node.js as in scope. OIDC has this covered.

3. My point with the 18 wheeler analogy is that yes, it is a vehicle that can take passengers, but it’s role is much more multi-purpose and heavy duty. For the developer that wants to securely take the kids to school, maybe just a Tesla Model S will do? This is less of a technical issue and more of a “market” issue. I know that’s hard for people like us to address, but it is a comment I keep hearing over and over (and not interestingly from Oracle itself).

4. As for confusion between OAuth’s intended authorization and a so called new authen function. This is the issue I’m trying to get on our agenda. This isn’t my idea, I am only the messenger. The fact is, developers and service providers who are not OAuth experts assume OAuth is about authentication and implement as such.  To some extent, this is  a market problem. Still, OIDC has not addressed the scenario. As John stated, OIDC choose not to do authen only.  

5. As for whether we “tack-on” authen to OAuth as OIDC does or whether we create a brand new endpoint or flow. I think that is open for discussion once the charter is adopted.  A4C is just an input draft - not the way the group needs to solve it.  A4C is intended to show the problem is solvable in a reasonably implementable manner.

Phil

@independentid
www.independentid.com
[email-masked]

On Jun 13, 2014, at 9:03 AM, Bill Burke <[email-masked]> wrote:

> I don't think this is true.  Most oidc oauth extensions are optional with the sole requirement that providers don't barf if you send them.
> 
> -- 
> Bill Burke

---

From: Anil Saldhana <[email-masked]>
Date: Fri, 13 Jun 2014 12:15:58 -0500

Phil - I want to hear who are those developers supporting a4c. You keep 
saying developers developers. I am not one of them.

This mailing list has clearly shown total disregard for the a4c 
proposal.  Please try to accept the community sentiment and 
unnecessarily don't extend this discussion into a lengthy email 
discussion when there is no clear acceptance for a4c.

---

From: Anil Saldhana <[email-masked]>
Date: Fri, 13 Jun 2014 12:26:50 -0500

> I still don't see the problem with having a deployment profile of Connect that can meet 100% of the current stated use case for a4c.
John - I am not fully familiar with the processes of OIDC.  How much of 
an effort is it to get the deployment profile of OIDC connect rolling?

---

From: Mike Jones <[email-masked]>
Date: Fri, 13 Jun 2014 17:31:42 +0000

I just looked all the uses of REQUIRED and MUST in the OpenID Connect Core spec.  They do things like say which claims are REQUIRED in the ID Token ("iss", "sub", etc.), which OAuth parameters and features are REQUIRED, place restrictions on certain values (such as "iss" MUST use the "https" scheme, "sub" must not be longer than 255 characters, the redirect_uri MUST exactly match a registered value, etc.), say that fields that are not understood MUST be ignored, and say when ID Tokens MUST be signed, and say that user interaction MUST NOT occur with prompt=none, and specify validation rules for some data structures (checking signatures, redirect_uris, etc.).

The key point is that none of the uses of REQUIRED or MUST require implementation of additional features, either by OPs or RPs.  They just place restrictions on *how* they are to be implemented.  So, in fact, the lists in 15.1 and 15.2 *are* comprehensive sets of required features for the two classes of identity providers.

I should have added in my earlier note that there's also a section on MTI features for RPs:
    15.4.<http://openid.net/specs/openid-connect-core-1_0.html#RPMTI>  Mandatory to Implement Features for Relying Parties
Essentially, it says that RPs only need to implement the features that they actually plan to use.

Developers have shown in practice to have no problem understanding the OpenID Connect specs or building interoperable implementations.  20 implementations (see http://osis.idcommons.net/wiki/Category:OC5_Solution) are participating in the current (5th) round of interop testing and a number of others also are privately.  The specs are clear to developers in part because we kept iterating, taking feedback, refining them, and doing new rounds of interop testing until they were clear and easy to build.  There's four years of implementation and deployment experience incorporated into the final specifications.

No, everyone won't build every optional feature.  That's a good thing - and by design.  The specs are designed to let you build only the parts that you need for your use cases, while still being interoperable for the features implemented.

Yes, the a4c spec adds a few things that OpenID Connect didn't - primarily the ability to authenticate over the back channel without issuing an ID Token by adding a new response_type, plus definitions of some claim values for the "amr" claim.  There's nothing wrong with these additions.

However, arguments that "OpenID Connect is too complicated" fall short in face of the actual implementation and deployment experience and I don't think are helpful to the current discussions.  We should be positively discussing what features OAuth specs should have, rather than trying to criticize other valuable work that's already widely deployed.

                                                            Best wishes,
                                                            -- Mike

From: Prateek Mishra [mailto:[email-masked]]
Sent: Friday, June 13, 2014 9:55 AM
To: Mike Jones; Bill Burke; Phil Hunt
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c

[quote]
This list augments the set of features that are already listed elsewhere as being "REQUIRED" or are described with a "MUST", and so is not, by itself, a comprehensive set of implementation requirements for OPs.
[\quote]

in Section 15.1, I have to say this isn't a clear definition of what is MTI.

I guess someone could through comprehensive research determine exactly what might be meant by this section, but that doesn't meet the criteria of "very clear definition of MTI".

- prateek

- prateek

                                                            -- Mike

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Prateek Mishra
Sent: Friday, June 13, 2014 9:24 AM
To: Bill Burke; Phil Hunt
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c

[quote]

[\quote]

OAuth mailing list

---

From: "Donald F. Coffin" <[email-masked]>
Date: Fri, 13 Jun 2014 11:47:14 -0700

+1

Best regards,
Don
Donald F. Coffin
Founder/CTO

REMI Networks
22751 El Prado Suite 6216
Rancho Santa Margarita, CA  92688-3836

Phone:      (949) 636-8571
Email:       [email-masked]

-----Original Message-----
From: Bill Burke [mailto:[email-masked]] 
Sent: Friday, June 13, 2014 9:22 AM
To: Prateek Mishra; IETF oauth WG
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c

On 6/13/2014 11:46 AM, Prateek Mishra wrote:
> featured that most people just implement some subset of their own 
> choice. I believe this is the case with all the large consumer web 
> sites.
>
> OAuth IETF. We have spent a lot of time lobbying for this outcome! 
> There is no question in my mind that the review within IETF would be 
> more comprehensive and expose the work to a larger community.
>

To create competing standards at IETF just because OIDC is not part of IETF,
IMO, is a disservice to the community.

---

From: "Donald F. Coffin" <[email-masked]>
Date: Fri, 13 Jun 2014 11:48:10 -0700

+1

Best regards,
Don
Donald F. Coffin
Founder/CTO

REMI Networks

Phone:      (949) 636-8571

-----Original Message-----
From: Anil Saldhana [mailto:[email-masked]] 
Sent: Friday, June 13, 2014 9:27 AM
To: [email-masked]
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c

Authentication needs to be outside its realm - whether it is OIDC, SAML or
other protocols, it is fine.

---

From: John Bradley <[email-masked]>
Date: Fri, 13 Jun 2014 15:11:14 -0400

Subsequent to this email Phil and I have talked.

There are two things that are deltas to connect in the spec.

One is the ability to issue only a id_token from the token endpoint.

The code grant_type requires a access token in the response.   If the WG wants to define a new grant type that doesn't return a access or refresh token that would be fine and it could be used with Connect as other grant types are.    The current use of a response_type in a4c to signal only returning a id_token and reusing the "code" grant type is a problem.
I think Mike J.  will be able to do an update with that shortly.

Phil is correct that Connect doesn't currently support that OAuth grant type because it has not been defined yet.  Not because you must provide claims at the token endpoint.

Connect supports the "id_token" and "none" response types nether of which provide access tokens.

For example a authn request with a scope of "openid" and a response_type of code will return a id_token and a access token for a user_info endpoint.   However the user_info endpoint will only only contain a claim for the "sub" that matches the "sub" in the id_token and not any photos of relatives, unless the IdP is horribly broken.

We need to balance returning a access token that may be discarded by the client that gives access to no PII vs adding a new grant_type.   
I think that would be a useful discussion that could feed back to Connect or a4c.

The other difference has to do with the use of authentication context and wanting to send a single value on a predefined scale vs an ordered list by preference.
This has been debated many times and many places.   The Connect approach recognizes that authentication contexts are not necessarily scalar.  
In SAML we do have the constructs of better than etc.  I think these are implemented and used almost nowhere.   
The Liberty/Kantara conformance testing only ever tested exact match.    So Connect did something similar to the option that is used in SAML.
I don't know that adding another way to ask for authentication context is helping the world.

This is perhaps a useful discussion, also independent of the specs though it may want informing from people at OASIS/Kantara who are not normally part of OAuth discussions.

I remain concerned that if we do a small core authentication spec in the OAuth WG that may start being compatible with Connect that opens the door to extensions down the road that may not be as people inevitably discover that there is more to life than the code flow.

I prefer to profile down Connect and support a new response type if that is desired rather than adding eventual confusion and incompatibility.

The main question for the work group at this point is if we want to change our charter to include authentication.   
If we do then a4c and other authentication related drafts can come into the WG.

At this point a4c is a independent draft.  

I am in favour of having a concise draft for basic identity providers, doing simple SSO. 
Connect has a Basic Client profile for people developing clients/RP/SP as there tend to be more of them than IdP.
The same thing can be done in the Connect WG as a Basic IdP profile.  

Going to far into debating the finer points of a4c is probably premature, until after a charter decision is reached.

Regards
John B.

---

From: Phil Hunt <[email-masked]>
Date: Fri, 13 Jun 2014 12:41:18 -0700

+1

Thanks John. 

Phil

> On Jun 13, 2014, at 12:11, John Bradley <[email-masked]> wrote:
>

---

From: John Bradley <[email-masked]>
Date: Fri, 13 Jun 2014 15:43:48 -0400

Hi Anil,

There are a number of profile efforts being looked at in the OIDF.   The Mobile Network operators lead by the GSMA are starting profile work on a standard profile that will be supported by mobile operators globally, that includes looking at how a Client/RP/SP can register there client once for use across multiple IdP AS, as well as standardized LoA and user-info schema extensions.

Torsten Lodderstedt is the chair of that effort and can chime in.

I suspect that a Basic IdP for SSO profile is significantly less ambitious than that and could be done in the current Connect WG.

If there is interest from the members to start it.   The main time blocking factor might be getting a new grant_type spec approved in the the OAuth WG if we wanted to support that.

The IdP profile is simple they can publish a discovery document saying they only support that that limited feature set, that way they would also be compatible with existing connect clients.

{
"scopes_supported": ["openid"],
"response_types_supported":["code"],
"response_modes_supported":["query"],
"grant_types_supported":["authorization_code", "code_id_token_only"],
"acr_values_supported":["2","3"]
}

They don't need to publish one if they don't intend to be discoverable to clients but knowing what the path forward to supporting generic client is helpful I think.

Everything exists now other than the new grant_type exists now.

The work would mostly be putting together the examples based on supporting a minimal flow.

Now I should point out that there are people who believe that the default flow should be implicit with the "id_token" response_type and intend to support that.
Phil's draft concentrates on only one use case.   Having a IdP deployment profile for it is not a problem, but it will not be for every IdP.   That is one of the reasons why discovery and registration are important features of Connect.

John B.

On Jun 13, 2014, at 1:26 PM, Anil Saldhana <[email-masked]> wrote:

> John - I am not fully familiar with the processes of OIDC.  How much of an effort is it to get the deployment profile of OIDC connect rolling?
> 
>>

---

From: Brian Campbell <[email-masked]>
Date: Fri, 13 Jun 2014 15:23:36 -0600

I agree that, at this point, debating the details of a4c is premature.
SSO/authentication are not part of the WG charter and, as I've said before,
I'd object to changing the charter to include it. Other than a small but
vocal minority, I think it's fair to say that that's also been the
prevailing sentiment of this group.

On Fri, Jun 13, 2014 at 1:43 PM, John Bradley <[email-masked]> wrote:

> Hi Anil,
>
> There are a number of profile efforts being looked at in the OIDF.   The
> Mobile Network operators lead by the GSMA are starting profile work on a
> standard profile that will be supported by mobile operators globally, that
> includes looking at how a Client/RP/SP can register there client once for
> use across multiple IdP AS, as well as standardized LoA and user-info
> schema extensions.
>
> I suspect that a Basic IdP for SSO profile is significantly less ambitious
> than that and could be done in the current Connect WG.
>
> If there is interest from the members to start it.   The main time
> blocking factor might be getting a new grant_type spec approved in the the
> OAuth WG if we wanted to support that.
>
> The IdP profile is simple they can publish a discovery document saying
> they only support that that limited feature set, that way they would also
> be compatible with existing connect clients.
>
> {
> They don't need to publish one if they don't intend to be discoverable to
> clients but knowing what the path forward to supporting generic client is
> helpful I think.
>
> Now I should point out that there are people who believe that the default
> flow should be implicit with the "id_token" response_type and intend to
> support that.
> Phil's draft concentrates on only one use case.   Having a IdP deployment
> profile for it is not a problem, but it will not be for every IdP.   That
> is one of the reasons why discovery and registration are important features
> of Connect.
>
> John B.
>
>
> >> Yes some companies chose not to participate for whatever reasons and
> have not committed to the mutual non assert IPR agreement, and that is
> unfortunate, but not a reason to start again from scratch.
> >>
> >> I think a profile of Connect introducing a grant_type returning only an
> id_token would be simpler than trying to do this as a separate spec.
> >> I do note that you can do effectively the same thing now by using a
> code response_type and a scope of openID.   This doesn't result in any
> extra user consent other than consenting to login to the RP the first time
> (though that consent can be given in advance out of band in a enterprise
> scenario.
> >>
> >> When developing Connect we debated having a token endpoint response
> with only a id_token but decided that it was not in the spirit of being a
> OAuth 2 profile.   So we decided to return a access token even if the user
> info endpoint contains no claims other then sub.   People almost always
> want more claims as they roll out a real deployment.  It is easy to add
> them if you have designed to be able to talk to a RS.
> >> a4c also completely ignores modern development environments like
> node.js where the client is in the user agent, that OAuth 2 and Connect
> support.
> >>
> >> By the time the OAuth WG is done with a4c it will likely be a similar
> size as Connect if it addresses the same use cases.
> >>
> >> I still don't see the problem with having a deployment profile of
> Connect that can meet 100% of the current stated use case for a4c.
> >> I expect that the people here involved in Connect will form there own
> opinions on comments regarding the number of participants and the quantity
> of the work and review.
> >>
> >> Regards
> >> John B.
> >>
> >>
> >>
> >>
> the
> Connect.

---

From: Anil Saldhana <[email-masked]>
Date: Fri, 13 Jun 2014 16:34:52 -0500

Brian - I agree. We should neither overload nor extend the WG charter to 
include any aspect of SSO or authentication.

I am hoping Prateek/Phil's feedback on OIDC can be addressed by OIDC.

 From John's email, it seemed like a path forward is a Deployment 
Profile at OIDC. Hopefully everybody will be happy with that.

On 06/13/2014 04:23 PM, Brian Campbell wrote:
> SSO/authentication are not part of the WG charter and, as I've said 
> before, I'd object to changing the charter to include it. Other than a 
> small but vocal minority, I think it's fair to say that that's also 
> been the prevailing sentiment of this group.
>
>
> On Fri, Jun 13, 2014 at 1:43 PM, John Bradley <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Anil,
>
>     There are a number of profile efforts being looked at in the OIDF.
>       The Mobile Network operators lead by the GSMA are starting
>     profile work on a standard profile that will be supported by
>     mobile operators globally, that includes looking at how a
>     Client/RP/SP can register there client once for use across
>     multiple IdP AS, as well as standardized LoA and user-info schema
>     extensions.
>
>     I suspect that a Basic IdP for SSO profile is significantly less
>     ambitious than that and could be done in the current Connect WG.
>
>     blocking factor might be getting a new grant_type spec approved in
>     the the OAuth WG if we wanted to support that.
>
>     The IdP profile is simple they can publish a discovery document
>     saying they only support that that limited feature set, that way
>     they would also be compatible with existing connect clients.
>
>     {
>     They don't need to publish one if they don't intend to be
>     discoverable to clients but knowing what the path forward to
>     supporting generic client is helpful I think.
>
>     Now I should point out that there are people who believe that the
>     default flow should be implicit with the "id_token" response_type
>     and intend to support that.
>     Phil's draft concentrates on only one use case.   Having a IdP
>     deployment profile for it is not a problem, but it will not be for
>     every IdP.   That is one of the reasons why discovery and
>     registration are important features of Connect.
>
>     John B.
>
>
>     On Jun 13, 2014, at 1:26 PM, Anil Saldhana
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>     >> Yes some companies chose not to participate for whatever
>     reasons and have not committed to the mutual non assert IPR
>     agreement, and that is unfortunate, but not a reason to start
>     again from scratch.
>     >>
>     >> Changing the OIDF IPR policy of totally open specifications
>     based on non asserts is also not a option.
>     >>
>     >> I think a profile of Connect introducing a grant_type returning
>     only an id_token would be simpler than trying to do this as a
>     separate spec.
>     >> I do note that you can do effectively the same thing now by
>     using a code response_type and a scope of openID.   This doesn't
>     result in any extra user consent other than consenting to login to
>     the RP the first time (though that consent can be given in advance
>     out of band in a enterprise scenario.
>     >>
>     >> When developing Connect we debated having a token endpoint
>     response with only a id_token but decided that it was not in the
>     spirit of being a OAuth 2 profile.   So we decided to return a
>     access token even if the user info endpoint contains no claims
>     other then sub.   People almost always want more claims as they
>     roll out a real deployment.  It is easy to add them if you have
>     designed to be able to talk to a RS.
>     >> a4c also completely ignores modern development environments
>     like node.js where the client is in the user agent, that OAuth 2
>     and Connect support.
>     >>
>     >> By the time the OAuth WG is done with a4c it will likely be a
>     similar size as Connect if it addresses the same use cases.
>     >>
>     >> I still don't see the problem with having a deployment profile
>     of Connect that can meet 100% of the current stated use case for a4c.
>     > John - I am not fully familiar with the processes of OIDC.  How
>     much of an effort is it to get the deployment profile of OIDC
>     connect rolling?
>     >
>     >>
>     >> I expect that the people here involved in Connect will form
>     there own opinions on comments regarding the number of
>     participants and the quantity of the work and review.
>     >>
>     >> Regards
>     >> John B.
>     >>
>     >>
>     >>
>     >>
>     >> On Jun 12, 2014, at 4:38 PM, Hans Zandbelt
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
>     >>
>     >>> +1, after implementing OIDC I will support the claim that any
>     SSO protocol with a minimal set of required features smaller than
>     OIDC is insecure and any protocol with similar features but with
>     different parameter names is just creating confusion and will
>     increase chances of non-interoperable and insecure implementations
>     >>>
>     >>> Hans.
>     >>>

---

From: Phil Hunt <[email-masked]>
Date: Fri, 13 Jun 2014 16:15:29 -0700

I think this is a false argument. What we desire to do or not do is not always the WG's choice.

It’s not me asking an authentication enhancement. The issue is whether to address improper authentication in the wild. Several of us all blogged about this a while a go and the problem with improper use of 6749 for authentication continues to grow.

Would it be better if we thought about this as the authentication “bug”?

I’m not sure everyone is on the same page regarding the term “authentication". In none of the scenarios discussed are we talking about “performing” authentication. We are talking about passing the authentication context from the AS in a non-opaque form to the client where the client is the audience of that information.

The authentication term is especially confusing because what developers *think* they are doing is authentication. It is not.

Phil

@independentid
www.independentid.com
[email-masked]

On Jun 13, 2014, at 2:34 PM, Anil Saldhana <[email-masked]> wrote:

> Brian - I agree. We should neither overload nor extend the WG charter to include any aspect of SSO or authentication.
> 
> From John's email, it seemed like a path forward is a Deployment Profile at OIDC. Hopefully everybody will be happy with that.
> 
> 
>> I agree that, at this point, debating the details of a4c is premature. SSO/authentication are not part of the WG charter and, as I've said before, I'd object to changing the charter to include it. Other than a small but vocal minority, I think it's fair to say that that's also been the prevailing sentiment of this group.  
>> 
>>

---

From: John Bradley <[email-masked]>
Date: Fri, 13 Jun 2014 19:50:23 -0400

To be precise SAML, Connect, and a4c provide Assertion-based authentication of a claimant,  by a Verifier (IdP) to a relying party (RP) when the RP and the Verifier are not collocated ( i.e., they are connected across a shared network)   SP-800-63 sec 9

Typically we call this authentication (authn) though that may just be a bad habit picked form SAML and other protocols use of the term.

It is true that people make horrible mistakes by ignoring the OAuth security considerations and inappropriately use OAuth directly for inferring that the presenter of the code or access token is the resource owner identified by the resource.

I had sort of hoped that broad support and adoption of OpenID Connect would help guide people in the correct direction.

If there is a need for a simpler IdP profile that is not interoperable across IdP (Not Dynamic) the question is if developers will be more motivated to use a profile of a larger standard as a starting point, or something presented as a limited authentication extension to OAuth 2.

Clearly nothing will stop some people from rolling there own authentication.  The question is what solution will get the best traction.

My fear is that if developers see this as two competing standards they will use that as justification to do there own thing rather than choose one.

At the end of the day what the profile looks like will likely be the same based on the use case.   The question is where will it be done and what do the politics look like to developers.

That is the short term question.

John B.

---

From: Bill Burke <[email-masked]>
Date: Fri, 13 Jun 2014 19:56:49 -0400

> Would it be better if we thought about this as the authentication “bug”?

How can there be an authentication "bug" when OIDC has addressed it 
backed by multiple implementations by different parties?  Why don't you 
see if OIDC addresses the minor optimizations you are proposing in a4c 
before creating competing specifications which will only confuse and 
fragment the community?

---

From: Paul Madsen <[email-masked]>
Date: Fri, 13 Jun 2014 20:10:36 -0400

let's not this disagreement over the need & relevance of a4c be 
conflated with the age-old blurriness between authz & authn - in no way 
are the two related

paul

On 6/13/14, 7:50 PM, John Bradley wrote:
> To be precise SAML, Connect, and a4c provide Assertion-based 
> authentication of a claimant,  by a Verifier (IdP) to a relying party 
> (RP) when the RP and the Verifier are not collocated ( i.e., they are 
> connected across a shared network)   SP-800-63 sec 9
>
> Typically we call this authentication (authn) though that may just be 
> a bad habit picked form SAML and other protocols use of the term.
>
> It is true that people make horrible mistakes by ignoring the OAuth 
> security considerations and inappropriately use OAuth directly for 
> inferring that the presenter of the code or access token is the 
> resource owner identified by the resource.
>
> I had sort of hoped that broad support and adoption of OpenID Connect 
> would help guide people in the correct direction.
>
> If there is a need for a simpler IdP profile that is not interoperable 
> across IdP (Not Dynamic) the question is if developers will be more 
> motivated to use a profile of a larger standard as a starting point, 
> or something presented as a limited authentication extension to OAuth 2.
>
> Clearly nothing will stop some people from rolling there own 
> authentication.  The question is what solution will get the best traction.
>
> My fear is that if developers see this as two competing standards they 
> will use that as justification to do there own thing rather than 
> choose one.
>
> At the end of the day what the profile looks like will likely be the 
> same based on the use case.   The question is where will it be done 
> and what do the politics look like to developers.
>
> On Jun 13, 2014, at 7:15 PM, Phil Hunt <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> It's not me asking an authentication enhancement. The issue is 
>> whether to address improper authentication in the wild. Several of us 
>> all blogged about this a while a go and the problem with improper use 
>> of 6749 for authentication continues to grow.
>>
>> Would it be better if we thought about this as the authentication "bug"?
>>
>> I'm not sure everyone is on the same page regarding the term 
>> "authentication". In none of the scenarios discussed are we talking 
>> about "performing" authentication. We are talking about passing the 
>> authentication context from the AS in a non-opaque form to the client 
>> where the client is the audience of that information.
>>
>> The authentication term is especially confusing because what 
>> developers *think* they are doing is authentication. It is not.
>>
>> Phil
>>
>> @independentid
>> www.independentid.com <http://www.independentid.com/>
>> [email-masked] <mailto:[email-masked]>
>>
>>
>>
>> On Jun 13, 2014, at 2:34 PM, Anil Saldhana <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>> Brian - I agree. We should neither overload nor extend the WG 
>>> charter to include any aspect of SSO or authentication.
>>>
>>>> I agree that, at this point, debating the details of a4c is 
>>>> premature. SSO/authentication are not part of the WG charter and, 
>>>> as I've said before, I'd object to changing the charter to include 
>>>> it. Other than a small but vocal minority, I think it's fair to say 
>>>> that that's also been the prevailing sentiment of this group.
>>>>
>>>>
>>>>     There are a number of profile efforts being looked at in the
>>>>     OIDF.   The Mobile Network operators lead by the GSMA are
>>>>     starting profile work on a standard profile that will be
>>>>     supported by mobile operators globally, that includes looking
>>>>     at how a Client/RP/SP can register there client once for use
>>>>     across multiple IdP AS, as well as standardized LoA and
>>>>     user-info schema extensions.
>>>>
>>>>     I suspect that a Basic IdP for SSO profile is significantly
>>>>     less ambitious than that and could be done in the current
>>>>     Connect WG.
>>>>
>>>>     If there is interest from the members to start it.   The main
>>>>     time blocking factor might be getting a new grant_type spec
>>>>     approved in the the OAuth WG if we wanted to support that.
>>>>
>>>>     saying they only support that that limited feature set, that
>>>>     way they would also be compatible with existing connect clients.
>>>>
>>>>     {
>>>>     Now I should point out that there are people who believe that
>>>>     the default flow should be implicit with the "id_token"
>>>>     response_type and intend to support that.
>>>>     deployment profile for it is not a problem, but it will not be
>>>>     for every IdP.   That is one of the reasons why discovery and
>>>>     >> I think a profile of Connect introducing a grant_type
>>>>     returning only an id_token would be simpler than trying to do
>>>>     this as a separate spec.
>>>>     using a code response_type and a scope of openID.   This
>>>>     doesn't result in any extra user consent other than consenting
>>>>     to login to the RP the first time (though that consent can be
>>>>     given in advance out of band in a enterprise scenario.
>>>>     >>
>>>>     response with only a id_token but decided that it was not in
>>>>     the spirit of being a OAuth 2 profile. So we decided to return
>>>>     a access token even if the user info endpoint contains no
>>>>     claims other then sub. People almost always want more claims as
>>>>     they roll out a real deployment.  It is easy to add them if you
>>>>     have designed to be able to talk to a RS.
>>>>     like node.js where the client is in the user agent, that OAuth
>>>>     2 and Connect support.
>>>>     >>
>>>>     >> By the time the OAuth WG is done with a4c it will likely be
>>>>     a similar size as Connect if it addresses the same use cases.
>>>>     >>
>>>>     >> I still don't see the problem with having a deployment
>>>>     profile of Connect that can meet 100% of the current stated use
>>>>     case for a4c.
>>>>     > John - I am not fully familiar with the processes of OIDC.
>>>>      How much of an effort is it to get the deployment profile of
>>>>     OIDC connect rolling?
>>>>     >
>>>>     >>
>>>>     <[email-masked]
>>>>     <mailto:[email-masked]>> wrote:
>>>>     >>
>>>>     >>> +1, after implementing OIDC I will support the claim that
>>>>     any SSO protocol with a minimal set of required features
>>>>     smaller than OIDC is insecure and any protocol with similar
>>>>     features but with different parameter names is just creating
>>>>     confusion and will increase chances of non-interoperable and
>>>>     insecure implementations
>>>>     >>>
>>>>     >>> Hans.
>>>>     >>>

---

From: Bill Mills <[email-masked]>
Date: Fri, 13 Jun 2014 19:25:15 -0700

Let's come back to the problem statement.  It sounds like Oauth is being (mis)used for plain authentication , we want to deal with that, and OpenID isn't appaently satisfying the need of the folks doing this.  Is that essentially correct?

What is the use case that the minimal OIDC implementation doesn't solve?

Is the problem that people want to use existing OAuth implementations and they would rather use/extend them than go to OIDC?

On Friday, June 13, 2014 4:15 PM, Phil Hunt <[email-masked]> wrote:

Phil

@independentid
[email-masked]

>>>There are a number of profile efforts being looked at in
              the OIDF.   The Mobile Network operators lead by the GSMA
              are starting profile work on a standard profile that will
              be supported by mobile operators globally, that includes
              looking at how a Client/RP/SP can register there client
              once for use across multiple IdP AS, as well as
              standardized LoA and user-info schema extensions.
>>>I suspect that a Basic IdP for SSO profile is
              significantly less ambitious than that and could be done
              in the current Connect WG.
>>>
>>>If there is interest from the members to start it.   The
              main time blocking factor might be getting a new
              grant_type spec approved in the the OAuth WG if we wanted
              to support that.
>>>
>>>The IdP profile is simple they can publish a discovery
              document saying they only support that that limited
              feature set, that way they would also be compatible with
              existing connect clients.
>>>They don't need to publish one if they don't intend to be
              discoverable to clients but knowing what the path forward
              to supporting generic client is helpful I think.
>>>Now I should point out that there are people who believe
              that the default flow should be implicit with the
              "id_token" response_type and intend to support that.
>>>Phil's draft concentrates on only one use case.   Having a
              IdP deployment profile for it is not a problem, but it
              will not be for every IdP.   That is one of the reasons
              why discovery and registration are important features of
              Connect.
>>>>> All but a handful of OAuth WG participants
                  participated in developing OpenID Connect.
>>>>>
>>>>> Yes some companies chose not to participate
                  for whatever reasons and have not committed to the
                  mutual non assert IPR agreement, and that is
                  unfortunate, but not a reason to start again from
                  scratch.
>>>>>
>>>>> Changing the OIDF IPR policy of totally open
                  specifications based on non asserts is also not a
                  option.
>>>>> I think a profile of Connect introducing a
                  grant_type returning only an id_token would be simpler
                  than trying to do this as a separate spec.
>>>>> I do note that you can do effectively the
                  same thing now by using a code response_type and a
                  scope of openID.   This doesn't result in any extra
                  user consent other than consenting to login to the RP
                  the first time (though that consent can be given in
                  advance out of band in a enterprise scenario.
>>>>>
>>>>> When developing Connect we debated having a
                  token endpoint response with only a id_token but
                  decided that it was not in the spirit of being a OAuth
                  2 profile.   So we decided to return a access token
                  even if the user info endpoint contains no claims
                  other then sub.   People almost always want more
                  claims as they roll out a real deployment.  It is easy
                  to add them if you have designed to be able to talk to
                  a RS.
>>>>> a4c also completely ignores modern
                  development environments like node.js where the client
                  is in the user agent, that OAuth 2 and Connect
                  support.
>>>>>
>>>>> By the time the OAuth WG is done with a4c it
                  will likely be a similar size as Connect if it
                  addresses the same use cases.
>>>>>
>>>>> I still don't see the problem with having a
                  deployment profile of Connect that can meet 100% of
                  the current stated use case for a4c.
>>>> John - I am not fully familiar with the processes
                  of OIDC.  How much of an effort is it to get the
                  deployment profile of OIDC connect rolling?
>>>>
>>>>>
>>>>> I expect that the people here involved in
                  Connect will form there own opinions on comments
                  regarding the number of participants and the quantity
                  of the work and review.
                  <[email-masked]> wrote:
>>>>>
>>>>>> +1, after implementing OIDC I will
                  support the claim that any SSO protocol with a minimal
                  set of required features smaller than OIDC is insecure
                  and any protocol with similar features but with
                  different parameter names is just creating confusion
                  and will increase chances of non-interoperable and
                  insecure implementations
>>>>>>>> received review from maybe a
                  dozen engineers within the OpenID community.
>>>>>>> this spec and/or the same
                  companies?!?  I think your energies are better

---

From: Justin Richer <[email-masked]>
Date: Sat, 14 Jun 2014 07:42:05 -0400

+1

This is clearly an extension to OIDC and should be handled in the OIDF 
so that it doesn't needlessly compete with OIDC. I see no reason for the 
IETF to take on this work.

  -- Justin

On 6/13/2014 5:34 PM, Anil Saldhana wrote:
> Brian - I agree. We should neither overload nor extend the WG charter 
> to include any aspect of SSO or authentication.
>
>> premature. SSO/authentication are not part of the WG charter and, as 
>> I've said before, I'd object to changing the charter to include it. 
>> Other than a small but vocal minority, I think it's fair to say that 
>> that's also been the prevailing sentiment of this group.
>>
>>
>>     supported by mobile operators globally, that includes looking at
>>     how a Client/RP/SP can register there client once for use across
>>     result in any extra user consent other than consenting to login
>>     to the RP the first time (though that consent can be given in