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 protected]> wrote: > 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. > > On May 22, 2014, at 10:59 AM, Anil Saldhana <[email protected]> > wrote: > > 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 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? > > Definitely. Anybody else? > > > John B. > > > On May 22, 2014, at 10:27 AM, Anil Saldhana <[email protected]> > wrote: > > 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: > > 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<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 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 >> >> > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
