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 protected]
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
