Phil, please do not misinform the working group.
My responses inline:
2014-05-22 3:56 GMT+09:00 Phil Hunt <[email protected]
<mailto:[email protected]>>:
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
<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 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
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.
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"] }}}
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.
OpenID Connect with scope=openid only is essentially the authN only
operation.
* 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.
This is supported by OpenID Connect as well.
o 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.
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 you can see the specs are doing similar things, but they
have different security features.
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.
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.
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
