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