+1 Thanks John.
Phil > On Jun 13, 2014, at 12:11, John Bradley <ve7...@ve7jtb.com> wrote: > > 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
