Hans, Torsten and I are working on the state draft that allows IdP initiated.
We haven't started documenting the rest of what would need to be in a profile, but I am guessing that it would be the Connect code flow for confidential clients to start. A version with the "id_token token" using proof of possession based on channel id would also be interesting but probably not generally deployable for a year, though having it ready in time for general browser deployment may be a nice change. This may or may not want to be in the OAuth WG. That will be up to the WG to decide. AS initiated OAuth 2 may be something that people are interested in without the identity layer. John B. On May 23, 2014, at 3:50 PM, Brian Campbell <[email protected]> wrote: > 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 ) 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 > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
