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
