Phil,
I thoroughly enjoy working with you whenever I can, and I really liked
your work on SCIM, but from the perspective of the web developers I work
with, I have a few concerns about what you wrote:
1. Developer experience and usability of the standards
You keep mentioning that web developers are demanding the new spec
because they don't understand/use OAuth2 properly. I estimate that most
people on this thread know web developers that they can claim to
represent -- so I'd rather hear what you think and why.
From my reading, the rough consensus appears to be that everyone agrees
that OIDC and OAuth2 could be improved, and better developer experience
is one of those improvements.
However, after reading your draft (basically because of Ian's
presentation) it does appear to me that some minor changes/additions to
OIDC would suffice. Personally, I don't see the requirement to NOT
return an access token as significant or even desirable in most use cases.
I'd rather focus on the one point in 30 years where the industry has
agreed on a core identity stack (OAuth2/OIDC/SCIM) and move on to
adoption and improved developer education/experience.
2. Standards bodies, corporations, and IPR issues
John's suggestion to link OIDC and an IETF draft for the minor additions
sounds reasonable as well, but, from my limited recent involvement, it
brings up a MUCH more concerning issue. I've always associated IETF as
the primary example of successful standards that are not overly
influenced by useless specs and large corporations. Interestingly,
overlarge, unnecessary specs and large corporations tend to go together.
Is the real issue here that some large corporations object to OIDF IPR
policy or weren't in the initial bandwagon -- so they must drive another
spec. Really? Is this just WS-Fed vs SAML again?
Personally, I'd hate to see the great individualistic, running-code,
rough-consensus body of the IETF do unnecessary (and market confusing)
work to satisfy a few lawyers' comfort zone.
--Dale
On 07/24/2014 08:57 AM, Phil Hunt wrote:
Nat,
You don't have to convince me.
You have to sell all the people not implementing OpenId who think
OAuth is sufficient.
I agree A4C is currently too long. I think Mike and John may be on to
something even better.
Phil
On Jul 24, 2014, at 11:50, Nat Sakimura <sakim...@gmail.com
<mailto:sakim...@gmail.com>> wrote:
2014-07-24 10:30 GMT-04:00 Phil Hunt <phil.h...@oracle.com
<mailto:phil.h...@oracle.com>>:
I’m not at all saying that OpenID is bad. If you want an IDP, its
fine. But if all a client wants is authentication, they think
why can’t I just use RFC6749?
If all what one wants is to build a simple client, there is a
standing document called OpenID Connect Basic Client Implementer's
Guide 1.0.
It is a profile that deals only the 'code' flow.
Size-wise, it is 32 pages. The break down are as below approximately:
Abstract, Intro, ToC - 2.5 pages
Terminology - 1.5 pages
Getting ID Token - 9 pages
ID Token Validation - 1 page (Seems missing from a4c draft?)
Userinfo Endpoint - 7 pages
Serializations - 1 page (missing in a4c?)
String Operations etc. - 1 pages (missing in a4c?)
Considerations - 2 pages (very brief in a4c)
References, Acknowledgement - 2 pages
Document History etc. - 7 pages
The a4c draft is 14 pages long. It will be longer than this in the
end as it is missing bunch of things.
The comparable portion of the Basic Client Profile is 14 pages or so.
Just one data point.
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
<https://urldefense.proofpoint.com/v1/url?u=http://nat.sakimura.org/&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=tZSv3T50ptdrF5VJeQfPow%3D%3D%0A&m=%2FHNlBS8t0nyksP6%2BTpUnVRbQACmczqcvThYucu1ZQ2w%3D%0A&s=732c8cb2c5d1c3c9a006c865feda78fd7564d8b192d20b2c7879bb53c23d25d9>
@_nat_en
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://urldefense.proofpoint.com/v1/url?u=https://www.ietf.org/mailman/listinfo/oauth&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=tZSv3T50ptdrF5VJeQfPow%3D%3D%0A&m=%2FHNlBS8t0nyksP6%2BTpUnVRbQACmczqcvThYucu1ZQ2w%3D%0A&s=a9405b77aec5d4156f53d2912a337b972dbbc4ba7ebd16121efbd325de47c65a
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
