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 protected]> wrote: > > Phil, please do not misinform the working group. > > My responses inline: > > > 2014-05-22 3:56 GMT+09:00 Phil Hunt <[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 ) 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 >> 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. >> 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 protected] >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
