Subject: [OAUTH-WG] Authen Milestone: Comparing current A4C proposal to OpenID Connect

From: Phil Hunt <[email-masked]>
Date: Wed, 21 May 2014 11:56:41 -0700

Since several have voiced the opinion that the WG should not work on providing user authentication context because OpenID Connect already has a solution, I wanted to make clear how A4C is different from OpenID Connect.

OpenID Connect supports providing clients an “id_token” using the id_token response type in section 3.2 (ImplicitAuth) and 3.3 (Hybrid Auth) of the OAuth Core.
http://openid.net/specs/openid-connect-core-1_0.html

The A4C draft that was put forward by Mike, Tony, and myself ( draft-hunt-oauth-v2-user-a4c ) describes a flow similar to the code flow of normal OAuth. Here are the differences from Connect:

Client Authentication
Connect does NOT authenticate the client prior to returning the id token. The Connect flow is single step returning ID_TOKEN to an unauthenticated client in both 3.2 and 3.3. Use of code flow in 3.3 appears only for the purpose of issuing an access token (user info token).
The A4C flow is 2-step following the OAuth2 code flow. It requires a code to be exchanged for ID_TOKEN after client authenticates in the second step (exactly duplicating the normal OAuth flow).  A4C requires mutual authentication of clients and AS service providers. A4C has the same logic and security properties of the normal OAuth authorization flow.
User Authentication 
Both OpenID Connect and A4C return ID tokens which contain pretty much the same information
A4C has additional features to allow clients to negotiate level of authentication and authentication types (min LOA,ACR,AMR) in addition to just returning ACR as in the case of OpenID.
A4C only make re-auth lighter weight. No need to issue UserInfo tokens again. Re-auth also re-authenticates the client as well as user.
Privacy Option
The A4C’s authentication of the client makes it possible to issue client-specific subject identifiers. This prevents multiple clients from colluding to share information.
Because Connect doesn’t know who the client is, the subject identifier returned is universal.
The spec could be used for pseudonymous authentication.

As you can see the specs are doing similar things, but they have different security features.

As for need:
There are many sites using social network providers to authenticate using 6749 only, there are ongoing security concerns that many of us have blogged about. This may rise to the level of BUG on 6749.
Some social network providers have indicated a willingness to support an authenticate only feature. I also had an inquiry if A4C can be supported in OAuth1 as well as OAuth2. Some of this may be coming from a business decision to use a proprietary user profile API instead (this is not Oracle’s position).
There is a consent problem because normal 6749 use requires users to consent to sharing information. Client developers in many cases would like an authen only profile where consent is implicit.
Developers have been indicating that defining new user-id/pwds  and additionally sharing of profile information both cut back on the %age success of new user registrations. Many want to offer an authenticate only option for their users where the users explicitly decide what to supply in their profile.  Pseudonymous authen is a basic feature.
I see other areas (e.g. Kitten) where authentication and re-authentication may be of interest to other IETF groups.
There may be much broader requirements in the IETF community that are not of interest to OpenID Connect and its objectives

While it is reasonable to make A4C and Connect as compatible as possible, I am not sure they can be compatible. A4C and Connect are two different flows solving different use cases with different security characteristics.

Note: I do not believe that the A4C draft is ready for last call-it is intended only as input to the WG process. The features and aspects like how the flow is initiated need to be discussed within the wider IETF community where broad consensus can be obtained. This is why I feel having it a work group milestone is important and I am willing to contribute my time towards it.

Because of the ongoing issue of inappropriate use of 6749 and the broader requirements within the IETF, I feel this work needs to be discussed within the IETF WG. 

Phil

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

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 22 May 2014 10:03:56 +0900

Phil, please do not misinform the working group.

My responses inline:

2014-05-22 3:56 GMT+09:00 Phil Hunt <[email-masked]>:

> Since several have voiced the opinion that the WG should not work on
> providing user authentication context because OpenID Connect already has a
> solution, I wanted to make clear how A4C is different from OpenID Connect.
>
> OpenID Connect supports providing clients an “id_token” using the id_token
> response type in section 3.2 (ImplicitAuth) and 3.3 (Hybrid Auth) of the
> OAuth Core.
> The A4C draft that was put forward by Mike, Tony, and myself (
> draft-hunt-oauth-v2-user-a4c<http://tools.ietf.org/id/draft-hunt-oauth-v2-user-a4c-02.txt> ) describes
> a flow similar to the code flow of normal OAuth. Here are the differences
> from Connect:
>
>
>    - Client Authentication
>       - Connect does NOT authenticate the client prior to returning the
>       id token. The Connect flow is single step returning ID_TOKEN to an
>       unauthenticated client in both 3.2 and 3.3. Use of code flow in 3.3 appears
>       only for the purpose of issuing an access token (user info token).
>       - The A4C flow is 2-step following the OAuth2 code flow. It
>       requires a code to be exchanged for ID_TOKEN after client authenticates in
>       the second step (exactly duplicating the normal OAuth flow).  A4C requires
>       mutual authentication of clients and AS service providers. A4C has the same
>       logic and security properties of the normal OAuth authorization flow.
>
> This is not true.

Connect for Code Flow for confidential client DOES authenticate the client
before getting an ID Token.

Further, the Connect has an option of asymmetrically encrypting ID Token
with the public key of the client, which authenticates the client even
further.
Even further, the Connect has an option of asymmetrically encrypting the
request with the public key of the server, which authenticates the server
in addition to TLS.

>
>    - User Authentication
>       - Both OpenID Connect and A4C return ID tokens which contain pretty
>       much the same information
>    - A4C has additional features to allow clients to negotiate level of
>       authentication and authentication types (min LOA,ACR,AMR) in addition to
>       just returning ACR as in the case of OpenID.
>
> What's the point of having both minimum LoA and AMR instead of ACR?
 Connect can also return AMR.
If you really wanted to have amr_values like feature, you can actually
request it by using Claims request as

{ "id_token": {"amr": {"values": ["otp","rsa"] }}}

>
>    - A4C only make re-auth lighter weight. No need to issue UserInfo
>       tokens again. Re-auth also re-authenticates the client as well as user.
>
>  I RFC6749 Section 5.1 REQUIRES an access token to be returned. A4C is
diverting from RFC6749. A4C is NOT OAuth anymore. The very reason OpenID
Connect returns an access token from the token endpoint always is to adhere
to RFC6749.

OpenID Connect with scope=openid only is essentially the authN only
operation.

>    - Privacy Option
>       - The A4C’s authentication of the client makes it possible to issue
>       client-specific subject identifiers. This prevents multiple clients from
>       colluding to share information.
>
> This is supported by OpenID Connect as well.

>
>    - Because Connect doesn’t know who the client is, the subject
>       identifier returned is universal.
>
> As stated above, this is false. It can even return PPID in the case of
public client as well.

>
>    - The spec could be used for pseudonymous authentication.
>
> As state above, OpenID Connect supports this. It in fact advise the use of
PPID (Pairwise Psuedonymous Identifier in section 17.3).

> As you can see the specs are doing similar things, but they have different

As stated above, I do not see much. It has less option in general, and
added feature is the amr_values and min_alv, which I do not see much value
in it but if you really wanted, you can extend the Connect.

>
> As for need:
>
>    - There are many sites using social network providers to authenticate
>    using 6749 only, there are ongoing security concerns that many of us have
>    blogged about. *This may rise to the level of BUG on 6749.*
>
> Why not just use OpenID Connect?

>
>    - Some social network providers have indicated a willingness to
>    support an authenticate only feature. I also had an inquiry if A4C can be
>    supported in OAuth1 as well as OAuth2. Some of this may be coming from a
>    business decision to use a proprietary user profile API instead (this is
>    not Oracle’s position).
>
> Authen only is fine with OpenID Connect. You can also use proprietary or
whatever the user profile API "in addition". For the purpose of
interoperability, it is better to have a standard user profile API though,
and that's why Connect defines a very basic one for this purpose.

>
>    - There is a consent problem because normal 6749 use requires users to
>    consent to sharing information. Client developers in many cases would like
>    an authen only profile where consent is implicit.
>
> That's an implementation issue. RFC 6749 does not require the users to
provide explicit consent.
It just states:

 the authorization server authenticates the resource owner and obtains

   an authorization decision (by asking the resource owner or by

   establishing approval via other means).

It can be implicit.

>
>    - Developers have been indicating that defining new user-id/pwds  and
>    additionally sharing of profile information both cut back on the %age
>    success of new user registrations. Many want to offer an authenticate only
>    option for their users where the users explicitly decide what to supply in
>    their profile.  Pseudonymous authen is a basic feature.
>
> This is supported by OpenID Connect as I stated above.

>
>    - I see other areas (e.g. Kitten) where authentication and
>    re-authentication may be of interest to other IETF groups.
>       - There may be much broader requirements in the IETF community that
>       are not of interest to OpenID Connect and its objectives
>
>
>
Why not?

> While it is reasonable to make A4C and Connect as compatible as possible,
> I am not sure they can be compatible. A4C and Connect are two different
> flows solving different use cases with different security characteristics.
>

Why not? I do not see it. You are essentially reading OpenID Connect wrong.

>
> Note: I do not believe that the A4C draft is ready for last call-it is
> intended only as input to the WG process. The features and aspects like how
> the flow is initiated need to be discussed within the wider IETF community
> where broad consensus can be obtained. This is why I feel having it a work
> group milestone is important and I am willing to contribute my time towards
> it.
>

Since it adds essentially nothing and produces wait-and-see among the
implementers, I think accepting this work as an work group item is actively
harmful for the internet. If something is needed to worked on in the work
group, I would rather want to see a profile of OpenID Connect referencing
it. That causes much less confusion.

>
> Because of the ongoing issue of inappropriate use of 6749 and the broader
> requirements within the IETF, I feel this work needs to be discussed within
> the IETF WG.
>
> Phil
>
> @independentid
> www.independentid.com
> [email-masked]
>
>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

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

---

From: John Bradley <[email-masked]>
Date: Wed, 21 May 2014 21:20:58 -0400

Thanks Nat. I can't add anything to your response. 

Let's base our decision on adding authentication to OAuth 2 on reality. 

Having a profile of Connect with most of the features Phil is looking for should not be a hard thing.   I don't personally think it is required to have that happen in the OAuth WG. 

John B

Sent from my iPhone

> On May 21, 2014, at 9:03 PM, Nat Sakimura <[email-masked]> wrote:
> 
> Connect for Code Flow for confidential client DOES authenticate the client before getting an ID Token. 
> 
> Further, the Connect has an option of asymmetrically encrypting ID Token with the public key of the client, which authenticates the client even further. 
> Even further, the Connect has an option of asymmetrically encrypting the request with the public key of the server, which authenticates the server in addition to TLS.  
>> User Authentication 
> What's the point of having both minimum LoA and AMR instead of ACR?  Connect can also return AMR. 
> If you really wanted to have amr_values like feature, you can actually request it by using Claims request as
> 
>  I RFC6749 Section 5.1 REQUIRES an access token to be returned. A4C is diverting from RFC6749. A4C is NOT OAuth anymore. The very reason OpenID Connect returns an access token from the token endpoint always is to adhere to RFC6749. 
> 
> OpenID Connect with scope=openid only is essentially the authN only operation. 
> 
>> Privacy Option
> As stated above, this is false. It can even return PPID in the case of public client as well. 
> As state above, OpenID Connect supports this. It in fact advise the use of PPID (Pairwise Psuedonymous Identifier in section 17.3). 
>  
>> 
> As stated above, I do not see much. It has less option in general, and added feature is the amr_values and min_alv, which I do not see much value in it but if you really wanted, you can extend the Connect. 
>  
>> 
>> As for need:
> Authen only is fine with OpenID Connect. You can also use proprietary or whatever the user profile API "in addition". For the purpose of interoperability, it is better to have a standard user profile API though, and that's why Connect defines a very basic one for this purpose.  
> That's an implementation issue. RFC 6749 does not require the users to provide explicit consent. 
> It just states: 
> 
> Since it adds essentially nothing and produces wait-and-see among the implementers, I think accepting this work as an work group item is actively harmful for the internet. If something is needed to worked on in the work group, I would rather want to see a profile of OpenID Connect referencing it. That causes much less confusion. 
>  
>>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 21 May 2014 19:07:19 -0700

I am offended. I may be wrong but I am NOT mis-informing. Please prove your case. 

Lets have a proper discussion. 

Phil

> On May 21, 2014, at 18:20, John Bradley <[email-masked]> wrote:
>

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 22 May 2014 19:15:36 +0900

it is all explained in my previous mail.

Cheers,

Nat

2014-05-22 11:07 GMT+09:00 Phil Hunt <[email-masked]>:

> Having a profile of Connect with most of the features Phil is looking for
> should not be a hard thing.   I don't personally think it is required to
> have that happen in the OAuth WG.
>
>
> John B
>
> Sent from my iPhone
>
>> OpenID Connect supports providing clients an “id_token” using the
>> id_token response type in section 3.2 (ImplicitAuth) and 3.3 (Hybrid Auth)
>> of the OAuth Core.
>>       - Both OpenID Connect and A4C return ID tokens which contain
>>       pretty much the same information
>>       - The A4C’s authentication of the client makes it possible to
>>       issue client-specific subject identifiers. This prevents multiple clients
>>       from colluding to share information.
>>
>> As state above, OpenID Connect supports this. It in fact advise the use
> of PPID (Pairwise Psuedonymous Identifier in section 17.3).
>
>
>>
>>    - There is a consent problem because normal 6749 use requires users
>>    to consent to sharing information. Client developers in many cases would
>>    like an authen only profile where consent is implicit.
>>
>>       - There may be much broader requirements in the IETF community
>>       that are not of interest to OpenID Connect and its objectives
>>
>>
>>
> Why not?
>
>

---

From: Anil Saldhana <[email-masked]>
Date: Thu, 22 May 2014 09:27:24 -0500

John/Nat - would it be easy if you both can set up an OIDC profile for 
this use case?

On 05/21/2014 08:20 PM, John Bradley wrote:
> Having a profile of Connect with most of the features Phil is looking 
> for should not be a hard thing.   I don't personally think it is 
> required to have that happen in the OAuth WG.
>
>
> John B
>
> Sent from my iPhone
>
> On May 21, 2014, at 9:03 PM, Nat Sakimura <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> 2014-05-22 3:56 GMT+09:00 Phil Hunt <[email-masked] 
>> <mailto:[email-masked]>>:
>>
>>     Since several have voiced the opinion that the WG should not work
>>     on providing user authentication context because OpenID Connect
>>     already has a solution, I wanted to make clear how A4C is
>>     different from OpenID Connect.
>>
>>     OpenID Connect supports providing clients an "id_token" using the
>>     id_token response type in section 3.2 (ImplicitAuth) and 3.3
>>     (Hybrid Auth) of the OAuth Core.
>>     draft-hunt-oauth-v2-user-a4c
>>     <http://tools.ietf.org/id/draft-hunt-oauth-v2-user-a4c-02.txt> ) describes
>>     a flow similar to the code flow of normal OAuth. Here are the
>>     differences from Connect:
>>
>>       * Client Authentication
>>           o Connect does NOT authenticate the client prior to
>>             returning the id token. The Connect flow is single step
>>             returning ID_TOKEN to an unauthenticated client in both
>>             3.2 and 3.3. Use of code flow in 3.3 appears only for the
>>             purpose of issuing an access token (user info token).
>>           o The A4C flow is 2-step following the OAuth2 code flow. It
>>             requires a code to be exchanged for ID_TOKEN after client
>>             authenticates in the second step (exactly duplicating the
>>             normal OAuth flow).  A4C requires mutual authentication
>>             of clients and AS service providers. A4C has the same
>> Further, the Connect has an option of asymmetrically encrypting ID 
>> Token with the public key of the client, which authenticates the 
>> client even further.
>> Even further, the Connect has an option of asymmetrically encrypting 
>> the request with the public key of the server, which authenticates 
>> the server in addition to TLS.
>>
>>       * User Authentication
>>           o Both OpenID Connect and A4C return ID tokens which
>>             contain pretty much the same information
>>           o A4C has additional features to allow clients to negotiate
>>             level of authentication and authentication types (min
>>             LOA,ACR,AMR) in addition to just returning ACR as in the
>>             case of OpenID.
>>
>> If you really wanted to have amr_values like feature, you can 
>> actually request it by using Claims request as
>>
>>           o A4C only make re-auth lighter weight. No need to issue
>>             UserInfo tokens again. Re-auth also re-authenticates the
>>             client as well as user.
>>
>>  I RFC6749 Section 5.1 REQUIRES an access token to be returned. A4C 
>> is diverting from RFC6749. A4C is NOT OAuth anymore. The very reason 
>> OpenID Connect returns an access token from the token endpoint always 
>> is to adhere to RFC6749.
>>
>>       * Privacy Option
>>           o The A4C's authentication of the client makes it possible
>>             to issue client-specific subject identifiers. This
>>             prevents multiple clients from colluding to share
>>             information.
>>
>>           o Because Connect doesn't know who the client is, the
>>             subject identifier returned is universal.
>>
>>           o The spec could be used for pseudonymous authentication.
>>
>> As state above, OpenID Connect supports this. It in fact advise the 
>> use of PPID (Pairwise Psuedonymous Identifier in section 17.3).
>>
>>
>> As stated above, I do not see much. It has less option in general, 
>> and added feature is the amr_values and min_alv, which I do not see 
>> much value in it but if you really wanted, you can extend the Connect.
>>
>>
>>     As for need:
>>
>>       * There are many sites using social network providers to
>>         authenticate using 6749 only, there are ongoing security
>>         concerns that many of us have blogged about. *This may rise
>>         to the level of BUG on 6749.*
>>
>>       * Some social network providers have indicated a willingness to
>>         support an authenticate only feature. I also had an inquiry
>>         if A4C can be supported in OAuth1 as well as OAuth2. Some of
>>         this may be coming from a business decision to use a
>>         proprietary user profile API instead (this is not Oracle's
>>         position).
>>
>> Authen only is fine with OpenID Connect. You can also use proprietary 
>> or whatever the user profile API "in addition". For the purpose of 
>> interoperability, it is better to have a standard user profile API 
>> though, and that's why Connect defines a very basic one for this 
>> purpose.
>>
>>       * There is a consent problem because normal 6749 use requires
>>         users to consent to sharing information. Client developers in
>>         many cases would like an authen only profile where consent is
>>         implicit.
>>
>>       * Developers have been indicating that defining new
>>         user-id/pwds  and additionally sharing of profile information
>>         both cut back on the %age success of new user registrations.
>>         Many want to offer an authenticate only option for their
>>         users where the users explicitly decide what to supply in
>>       * I see other areas (e.g. Kitten) where authentication and
>>           o There may be much broader requirements in the IETF
>>             community that are not of interest to OpenID Connect and
>>             its objectives
>>
>>
>>
>> Why not?
>>
>>     While it is reasonable to make A4C and Connect as compatible as
>>     possible, I am not sure they can be compatible. A4C and Connect
>>     are two different flows solving different use cases with
>>     different security characteristics.
>>
>>
>>     Note: I do not believe that the A4C draft is ready for last
>>     call-it is intended only as input to the WG process. The features
>>     and aspects like how the flow is initiated need to be discussed
>>     within the wider IETF community where broad consensus can be
>>     obtained. This is why I feel having it a work group milestone is
>>     important and I am willing to contribute my time towards it.
>>
>>
>> implementers, I think accepting this work as an work group item is 
>> actively harmful for the internet. If something is needed to worked 
>> on in the work group, I would rather want to see a profile of OpenID 
>> Connect referencing it. That causes much less confusion.
>>
>>
>>     Because of the ongoing issue of inappropriate use of 6749 and the
>>     broader requirements within the IETF, I feel this work needs to
>>     be discussed within the IETF WG.
>>
>>     Phil
>>

---

From: John Bradley <[email-masked]>
Date: Thu, 22 May 2014 10:49:51 -0400

Last week I was under the impression that Mike was working with Phil to come up with a profile of Connect that basically takes a subset of the basic client profile, and doesn't require changes to OAuth.

I was waiting to look at that revision before digging back into this.

That is likely still happening despite the confusion caused by this thread.   

I am considering doing a ID showing how the Connect Basic profile can be used to replace proprietary SSO connectors.
That would include a reference to http://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state as a way to do do IdP initiated.

Basically the existing profile with a single IdP and client credentials and reiterating the explanation from AOuth that scopes can be implicit and consent can be granted out of band.

That would allow a SAML to Connect proxy as an example.

Having more than one input document may help the WG understand the issues better.  

Interested in discussing it?

John B.

On May 22, 2014, at 10:27 AM, Anil Saldhana <[email-masked]> wrote: 

> John/Nat - would it be easy if you both can set up an OIDC profile for this use case?
>

---

From: Anil Saldhana <[email-masked]>
Date: Thu, 22 May 2014 09:59:25 -0500

On 05/22/2014 09:49 AM, John Bradley wrote:
> Last week I was under the impression that Mike was working with Phil 
> to come up with a profile of Connect that basically takes a subset of 
> the basic client profile, and doesn't require changes to OAuth.
>
> I am considering doing a ID showing how the Connect Basic profile can 
> be used to replace proprietary SSO connectors.
> That would include a reference to 
> http://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state as a 
> way to do do IdP initiated.
>
> Basically the existing profile with a single IdP and client 
> credentials and reiterating the explanation from AOuth that scopes can 
> be implicit and consent can be granted out of band.
>
Definitely.  Anybody else?
>
> John B.
>
>
> On May 22, 2014, at 10:27 AM, Anil Saldhana <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>>> Having a profile of Connect with most of the features Phil is 
>>> looking for should not be a hard thing.   I don't personally think 
>>> it is required to have that happen in the OAuth WG.
>>>
>>>
>>> John B
>>>
>>> Sent from my iPhone
>>>
>>>>     Since several have voiced the opinion that the WG should not
>>>>     work on providing user authentication context because OpenID
>>>>     Connect already has a solution, I wanted to make clear how A4C
>>>>     is different from OpenID Connect.
>>>>
>>>>     OpenID Connect supports providing clients an “id_token” using
>>>>     the id_token response type in section 3.2 (ImplicitAuth) and
>>>>     3.3 (Hybrid Auth) of the OAuth Core.
>>>>             3.2 and 3.3. Use of code flow in 3.3 appears only for
>>>>             the purpose of issuing an access token (user info token).
>>>>           o The A4C flow is 2-step following the OAuth2 code flow.
>>>>             It requires a code to be exchanged for ID_TOKEN after
>>>>             client authenticates in the second step (exactly
>>>>             duplicating the normal OAuth flow).  A4C requires
>>>>             mutual authentication of clients and AS service
>>>>             providers. A4C has the same logic and security
>>>>             properties of the normal OAuth authorization flow.
>>>>
>>>> This is not true.
>>>>
>>>> Even further, the Connect has an option of asymmetrically 
>>>> encrypting the request with the public key of the server, which 
>>>> authenticates the server in addition to TLS.
>>>>
>>>>       * User Authentication
>>>>           o A4C has additional features to allow clients to
>>>>             negotiate level of authentication and authentication
>>>>             types (min LOA,ACR,AMR) in addition to just returning
>>>>             ACR as in the case of OpenID.
>>>>
>>>>             UserInfo tokens again. Re-auth also re-authenticates
>>>>             the client as well as user.
>>>>
>>>> is diverting from RFC6749. A4C is NOT OAuth anymore. The very 
>>>> reason OpenID Connect returns an access token from the token 
>>>> endpoint always is to adhere to RFC6749.
>>>>
>>>>           o The A4C’s authentication of the client makes it
>>>>             possible to issue client-specific subject identifiers.
>>>>             This prevents multiple clients from colluding to share
>>>>             information.
>>>>
>>>>           o Because Connect doesn’t know who the client is, the
>>>>       * Some social network providers have indicated a willingness
>>>>         to support an authenticate only feature. I also had an
>>>>         inquiry if A4C can be supported in OAuth1 as well as
>>>>         OAuth2. Some of this may be coming from a business decision
>>>>         to use a proprietary user profile API instead (this is not
>>>>         Oracle’s position).
>>>>
>>>> Authen only is fine with OpenID Connect. You can also use 
>>>> proprietary or whatever the user profile API "in addition". For the 
>>>> purpose of interoperability, it is better to have a standard user 
>>>> profile API though, and that's why Connect defines a very basic one 
>>>> for this purpose.
>>>>
>>>>         users to consent to sharing information. Client developers
>>>>         in many cases would like an authen only profile where
>>>>         consent is implicit.
>>>>
>>>>         user-id/pwds  and additionally sharing of profile
>>>>         information both cut back on the %age success of new user
>>>>         registrations. Many want to offer an authenticate only
>>>>         option for their users where the users explicitly decide
>>>>         what to supply in their profile.  Pseudonymous authen is a
>>>>         basic feature.
>>>>
>>>>             community that are not of interest to OpenID Connect
>>>>             and its objectives
>>>>
>>>>
>>>>
>>>> Why not?
>>>>
>>>>     call-it is intended only as input to the WG process. The
>>>>     features and aspects like how the flow is initiated need to be
>>>>     discussed within the wider IETF community where broad consensus
>>>>     can be obtained. This is why I feel having it a work group
>>>>     milestone is important and I am willing to contribute my time
>>>>     towards it.
>>>>
>>>>
>>>> Since it adds essentially nothing and produces wait-and-see among 
>>>> the implementers, I think accepting this work as an work group item 
>>>> is actively harmful for the internet. If something is needed to 
>>>> worked on in the work group, I would rather want to see a profile 
>>>> of OpenID Connect referencing it. That causes much less confusion.
>>>>
>>>>
>>>>     Because of the ongoing issue of inappropriate use of 6749 and
>>>>     the broader requirements within the IETF, I feel this work
>>>>     needs to be discussed within the IETF WG.
>>>>
>>>>     Phil
>>>>
>> [email-masked] <mailto:[email-masked]>

---

From: John Bradley <[email-masked]>
Date: Thu, 22 May 2014 11:02:15 -0400

I was thinking of asking Brian Campbell as long as he doesn't let it go to his head.

I expect Layer7 and others might also have an interest in such a thing.

John B.

---

From: Anil Saldhana <[email-masked]>
Date: Thu, 22 May 2014 10:58:11 -0500

> I was thinking of asking Brian Campbell as long as he doesn't let it 
Probably he needs Paul Madsen's blessings. :-)
> I expect Layer7 and others might also have an interest in such a thing.
I will have a couple of guys on our side lined up.

> John B.
>
> On May 22, 2014, at 10:59 AM, Anil Saldhana <[email-masked] 
>>> to come up with a profile of Connect that basically takes a subset 
>>> of the basic client profile, and doesn't require changes to OAuth.
>>>
>>> I am considering doing a ID showing how the Connect Basic profile 
>>> can be used to replace proprietary SSO connectors.
>>> http://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state as 
>>> a way to do do IdP initiated.
>>>
>>> credentials and reiterating the explanation from AOuth that scopes 
>>> can be implicit and consent can be granted out of band.
>>>
>>> On May 22, 2014, at 10:27 AM, Anil Saldhana 
>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>>>>     Connect already has a solution, I wanted to make clear how
>>>>>>     A4C is different from OpenID Connect.
>>>>>>
>>>>>>     The A4C draft that was put forward by Mike, Tony, and myself
>>>>>>     ( draft-hunt-oauth-v2-user-a4c
>>>>>>             returning the id token. The Connect flow is single
>>>>>>             step returning ID_TOKEN to an unauthenticated client
>>>>>>             in both 3.2 and 3.3. Use of code flow in 3.3 appears
>>>>>>           o The A4C flow is 2-step following the OAuth2 code
>>>>>>             flow. It requires a code to be exchanged for ID_TOKEN
>>>>>>             after client authenticates in the second step
>>>>>>             (exactly duplicating the normal OAuth flow).  A4C
>>>>>>             requires mutual authentication of clients and AS
>>>>>>             service providers. A4C has the same logic and
>>>>>>             security properties of the normal OAuth authorization
>>>>>>             flow.
>>>>>>
>>>>>> This is not true.
>>>>>>
>>>>>> Further, the Connect has an option of asymmetrically encrypting 
>>>>>> ID Token with the public key of the client, which authenticates 
>>>>>> the client even further.
>>>>>>           o A4C only make re-auth lighter weight. No need to
>>>>>>             issue UserInfo tokens again. Re-auth also
>>>>>>             re-authenticates the client as well as user.
>>>>>>
>>>>>>  I RFC6749 Section 5.1 REQUIRES an access token to be returned. 
>>>>>> A4C is diverting from RFC6749. A4C is NOT OAuth anymore. The very 
>>>>>>             possible to issue client-specific subject
>>>>>>             identifiers. This prevents multiple clients from
>>>>>> As state above, OpenID Connect supports this. It in fact advise 
>>>>>> the use of PPID (Pairwise Psuedonymous Identifier in section 17.3).
>>>>>>
>>>>>>
>>>>>> As stated above, I do not see much. It has less option in 
>>>>>> general, and added feature is the amr_values and min_alv, which I 
>>>>>> do not see much value in it but if you really wanted, you can 
>>>>>> extend the Connect.
>>>>>>
>>>>>>
>>>>>>     As for need:
>>>>>>
>>>>>>         concerns that many of us have blogged about. *This may
>>>>>>         rise to the level of BUG on 6749.*
>>>>>>
>>>>>>       * Some social network providers have indicated a
>>>>>>         willingness to support an authenticate only feature. I
>>>>>>         also had an inquiry if A4C can be supported in OAuth1 as
>>>>>>         well as OAuth2. Some of this may be coming from a
>>>>>>         business decision to use a proprietary user profile API
>>>>>>         instead (this is not Oracle’s position).
>>>>>>
>>>>>> proprietary or whatever the user profile API "in addition". For 
>>>>>> the purpose of interoperability, it is better to have a standard 
>>>>>> user profile API though, and that's why Connect defines a very 
>>>>>> basic one for this purpose.
>>>>>>
>>>>>>       * There is a consent problem because normal 6749 use
>>>>>>         requires users to consent to sharing information. Client
>>>>>>         developers in many cases would like an authen only
>>>>>>         profile where consent is implicit.
>>>>>>
>>>>>>         what to supply in their profile.  Pseudonymous authen is
>>>>>>         a basic feature.
>>>>>>
>>>>>>     While it is reasonable to make A4C and Connect as compatible
>>>>>>     as possible, I am not sure they can be compatible. A4C and
>>>>>>     Connect are two different flows solving different use cases
>>>>>>     with different security characteristics.
>>>>>>
>>>>>>
>>>>>>     features and aspects like how the flow is initiated need to
>>>>>>     be discussed within the wider IETF community where broad
>>>>>>     consensus can be obtained. This is why I feel having it a
>>>>>>     work group milestone is important and I am willing to
>>>>>>     contribute my time towards it.
>>>>>>
>>>>>>
>>>>>> the implementers, I think accepting this work as an work group 
>>>>>> item is actively harmful for the internet. If something is needed 
>>>>>> to worked on in the work group, I would rather want to see a 
>>>>>> profile of OpenID Connect referencing it. That causes much less 
>>>>>> confusion.
>>>>>>
>>>>>>

---

From: John Bradley <[email-masked]>
Date: Thu, 22 May 2014 12:07:38 -0400

I posted a update to http://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state-01 

Hans has also updated the Connect Apache module with a first cut of support as a reference https://github.com/pingidentity/mod_auth_openidc.

As it turns out the additional code was shorter than the spec.

John B.

---

From: Brian Campbell <[email-masked]>
Date: Fri, 23 May 2014 13:50:39 -0600

Simply having you acknowledge my existence goes to my head, John.

I'd be interested in discussing it for sure. I have some reservations
and/or confusion regarding your approach but need to actually read the
draft before I say anything more. Which I'll try and do at some point here
before too long.

On Thu, May 22, 2014 at 9:02 AM, John Bradley <[email-masked]> wrote:

> Last week I was under the impression that Mike was working with Phil to
> come up with a profile of Connect that basically takes a subset of the
> basic client profile, and doesn't require changes to OAuth.
>
>  I am considering doing a ID showing how the Connect Basic profile can be
> used to replace proprietary SSO connectors.
> http://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state as a way
> to do do IdP initiated.
>
>  Basically the existing profile with a single IdP and client credentials
> and reiterating the explanation from AOuth that scopes can be implicit and
> consent can be granted out of band.
>
> for should not be a hard thing.   I don't personally think it is required
> to have that happen in the OAuth WG.
>
>
>  John B
>
> Sent from my iPhone
>
>> possible, I am not sure they can be compatible. A4C and Connect are two
>> different flows solving different use cases with different security
>> characteristics.
>>
>
>> broader requirements within the IETF, I feel this work needs to be
>> discussed within the IETF WG.
>>
>>        Phil
>>
>>

---

From: John Bradley <[email-masked]>
Date: Fri, 23 May 2014 16:01:15 -0400

Hans, Torsten and I are working on the state draft that allows IdP initiated.

We haven't started documenting the rest of what would need to be in a profile, but I am guessing that it would be the Connect code flow for confidential clients to start.

A version with the "id_token token"  using proof of possession based on channel id would also be interesting but probably not generally deployable for a year, though having it ready in time for general browser deployment may be a nice change.

This may or may not want to be in the OAuth WG.  That will be up to the WG to decide.   

AS initiated OAuth 2 may be something that people are interested in without the identity layer.

John B.

On May 23, 2014, at 3:50 PM, Brian Campbell <[email-masked]> wrote:

> I'd be interested in discussing it for sure. I have some reservations and/or confusion regarding your approach but need to actually read the draft before I say anything more. Which I'll try and do at some point here before too long.
> 
>