Subsequent to this email Phil and I have talked. There are two things that are deltas to connect in the spec.
One is the ability to issue only a id_token from the token endpoint. The code grant_type requires a access token in the response. If the WG wants to define a new grant type that doesn't return a access or refresh token that would be fine and it could be used with Connect as other grant types are. The current use of a response_type in a4c to signal only returning a id_token and reusing the "code" grant type is a problem. I think Mike J. will be able to do an update with that shortly. Phil is correct that Connect doesn't currently support that OAuth grant type because it has not been defined yet. Not because you must provide claims at the token endpoint. Connect supports the "id_token" and "none" response types nether of which provide access tokens. For example a authn request with a scope of "openid" and a response_type of code will return a id_token and a access token for a user_info endpoint. However the user_info endpoint will only only contain a claim for the "sub" that matches the "sub" in the id_token and not any photos of relatives, unless the IdP is horribly broken. We need to balance returning a access token that may be discarded by the client that gives access to no PII vs adding a new grant_type. I think that would be a useful discussion that could feed back to Connect or a4c. The other difference has to do with the use of authentication context and wanting to send a single value on a predefined scale vs an ordered list by preference. This has been debated many times and many places. The Connect approach recognizes that authentication contexts are not necessarily scalar. In SAML we do have the constructs of better than etc. I think these are implemented and used almost nowhere. The Liberty/Kantara conformance testing only ever tested exact match. So Connect did something similar to the option that is used in SAML. I don't know that adding another way to ask for authentication context is helping the world. This is perhaps a useful discussion, also independent of the specs though it may want informing from people at OASIS/Kantara who are not normally part of OAuth discussions. I remain concerned that if we do a small core authentication spec in the OAuth WG that may start being compatible with Connect that opens the door to extensions down the road that may not be as people inevitably discover that there is more to life than the code flow. I prefer to profile down Connect and support a new response type if that is desired rather than adding eventual confusion and incompatibility. The main question for the work group at this point is if we want to change our charter to include authentication. If we do then a4c and other authentication related drafts can come into the WG. At this point a4c is a independent draft. I am in favour of having a concise draft for basic identity providers, doing simple SSO. Connect has a Basic Client profile for people developing clients/RP/SP as there tend to be more of them than IdP. The same thing can be done in the Connect WG as a Basic IdP profile. Going to far into debating the finer points of a4c is probably premature, until after a charter decision is reached. Regards John B. On Jun 13, 2014, at 1:10 PM, Phil Hunt <phil.h...@oracle.com> wrote: > I am going to address a few comments all together here: > > 1. John Bradley confirmed again yesterday, OIDC does not allow for > authentication only as part of the normal code flow and decided intentionally > not to address it. So to say OIDC has a solution is confusing. > > OIDC has the solution if you want to propagate profile information and authen > information. This means service providers have to implement much more code, > and clients have to as well. For many there are customer abandonment and > legal issues around sharing of too much PII information. They DO NOT want to > have to ask for this information. > > 2. Regarding speculative future size: I point out that the A4C draft is > modelled exactly on the authorizaiton flow and has exactly the same security > model. Therefore I would not expect any large increase in size, but rather > the opposite. The number 1 challenge with this spec is not figuring out how > to do this, but how to avoid scope creep into OIDC’s coverage. I do NOT > support scope creep into OIDC. > > We need a specific draft that addresses the issues of developers thinking > 6749 is sufficient on its own. I do NOT want to see stuff like browser based > apps and node.js as in scope. OIDC has this covered. > > 3. My point with the 18 wheeler analogy is that yes, it is a vehicle that can > take passengers, but it’s role is much more multi-purpose and heavy duty. For > the developer that wants to securely take the kids to school, maybe just a > Tesla Model S will do? This is less of a technical issue and more of a > “market” issue. I know that’s hard for people like us to address, but it is a > comment I keep hearing over and over (and not interestingly from Oracle > itself). > > 4. As for confusion between OAuth’s intended authorization and a so called > new authen function. This is the issue I’m trying to get on our agenda. This > isn’t my idea, I am only the messenger. The fact is, developers and service > providers who are not OAuth experts assume OAuth is about authentication and > implement as such. To some extent, this is a market problem. Still, OIDC > has not addressed the scenario. As John stated, OIDC choose not to do authen > only. > > 5. As for whether we “tack-on” authen to OAuth as OIDC does or whether we > create a brand new endpoint or flow. I think that is open for discussion once > the charter is adopted. A4C is just an input draft - not the way the group > needs to solve it. A4C is intended to show the problem is solvable in a > reasonably implementable manner. > > Phil > > @independentid > www.independentid.com > phil.h...@oracle.com > > > > On Jun 13, 2014, at 9:03 AM, Bill Burke <bbu...@redhat.com> wrote: > >> >> >> On 6/12/2014 4:18 PM, Phil Hunt wrote: >>> >>> >>> Phil >>> >>>> On Jun 12, 2014, at 12:50, Bill Burke <bbu...@redhat.com> wrote: >>>> >>>> >>>> >>>>> On 6/12/2014 12:49 PM, Prateek Mishra wrote: >>>>> The OpenID Connect 2.0 COre specification alone is 86 pages. It has >>>>> received review from maybe a dozen engineers within the OpenID community. >>>> >>>> The OpenID Connect spec is 86 pages because it pretty much rehashes the >>>> OAuth2 spec walking through each flow and how Open ID Connect expands on >>>> that flow. A4c looks like a subset of this work minus some additional >>>> claims and, IMO, is incomplete compared to OIDC. >>> In what regards? >>> >>> Much of oidc is out of scope for this requirement. >>> >> >> What is in a4c that isn't already in OIDC? >> >>> It is a bit like saying an 18 wheeler is suitable for driving the kids to >>> school. :-) >> >> I don't think this is true. Most oidc oauth extensions are optional with >> the sole requirement that providers don't barf if you send them. >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
