Phil - I want to hear who are those developers supporting a4c. You keep
saying developers developers. I am not one of them.
This mailing list has clearly shown total disregard for the a4c
proposal. Please try to accept the community sentiment and
unnecessarily don't extend this discussion into a lengthy email
discussion when there is no clear acceptance for a4c.
On 06/13/2014 12:10 PM, Phil Hunt 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.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
