"I had personally requested the OIDC community about six months ago to describe some minimal subset which we could all reasonably implement."
I believe you're looking for this: http://openid.net/specs/openid-connect-basic-1_0.html -cmort On Wed, May 14, 2014 at 5:37 PM, Prateek Mishra <prateek.mis...@oracle.com>wrote: > Anil, > > the challenge is that OIDC is a rather large set of specifications, and to > my knowledge even the core specification has NOT found > a complete implementation at any large IdP. I am not talking here about > boutique toolkits or startups, I am talking about the folks > who have 100s of millions of users. And, BTW, implementing a few > arbitrarily selected features from OIDC is not the same as implementing > OIDC. > > As we all know, the core problem is that of adding an authenticator token > to OAuth flows, which is a rather modest extension to OAuth. > > I had personally requested the OIDC community about six months ago to > describe some minimal subset which we could all reasonably implement. I was > told that the specification was "locked down" and fully debugged and so > on, so no changes could be made. Imagine my surprise to find that in the > final drafts there was a whole new flow - the hybrid flow - that had been > added at the last minute. I had never heard of the hybrid flow in the OAuth > context - have you? So now you have an even larger specification! > > The value of draft-hunt-oauth-v2-user-a4c-01 is that it describes > precisely a minimal extension to OAuth flows to support an authenticator > token. In my experience, this is the subset that most customers and > implementors are looking for. > > > - prateek > > > > > > Tony/Phil, > any chance you can have this work done at OIDC? > > The reason is that it is commonly understood/accepted now that OAuth > provides authorization related specs while authentication/profile > related specs are coming from OIDC (which builds on top of OAuth2). > > Regards, > Anil > > On 05/14/2014 10:47 AM, Anthony Nadalin wrote: > > I agree with Phil on this one, there are implementations of this already > and much interest > > > > *From:* OAuth [mailto:oauth-boun...@ietf.org <oauth-boun...@ietf.org>] *On > Behalf Of *Phil Hunt > *Sent:* Wednesday, May 14, 2014 8:32 AM > *To:* Brian Campbell > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] OAuth Milestone Update and Rechartering > > > > On the contrary. I and others are interested. > > > > We are waiting for the charter to pick up the work. > > > > Regardless there will be a new draft shortly. > > > Phil > > > On May 14, 2014, at 5:24, Brian Campbell <bcampb...@pingidentity.com> > wrote: > > I would object to 'OAuth Authentication' being picked up by the WG as a > work item. The starting point draft has expired and it hasn't really been > discusses since Berlin nearly a year ago. As I recall, there was only very > limited interest in it even then. I also don't believe it fits well with > the WG charter. > > I would suggest the WG consider picking up 'OAuth Symmetric Proof of > Possession for Code Extension' for which there is an excellent starting > point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a > relativity simple security enhancement which addresses problems currently > being encountered in deployments of native clients. > > > > On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig < > hannes.tschofe...@gmx.net> wrote: > > Hi all, > > you might have seen that we pushed the assertion documents and the JWT > documents to the IESG today. We have also updated the milestones on the > OAuth WG page. > > This means that we can plan to pick up new work in the group. > We have sent a request to Kathleen to change the milestone for the OAuth > security mechanisms to use the proof-of-possession terminology. > > We also expect an updated version of the dynamic client registration > spec incorporating last call feedback within about 2 weeks. > > We would like you to think about adding the following milestones to the > charter as part of the re-chartering effort: > > ----- > > Nov 2014 Submit 'Token introspection' to the IESG for consideration as a > Proposed Standard > Starting point: <draft-richer-oauth-introspection-04> > > Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as > a Proposed Standard > Starting point: <draft-hunt-oauth-v2-user-a4c-01> > > Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a > Proposed Standard > Starting point: <draft-jones-oauth-token-exchange-00> > > ----- > > We also updated the charter text to reflect the current situation. Here > is the proposed text: > > ----- > > Charter for Working Group > > > The Web Authorization (OAuth) protocol allows a user to grant a > third-party Web site or application access to the user's protected > resources, without necessarily revealing their long-term credentials, > or even their identity. For example, a photo-sharing site that > supports OAuth could allow its users to use a third-party printing Web > site to print their private pictures, without allowing the printing > site to gain full control of the user's account and without having the > user share his or her photo-sharing sites' long-term credential with > the printing site. > > The OAuth 2.0 protocol suite encompasses > > * a protocol for obtaining access tokens from an authorization > server with the resource owner's consent, > * protocols for presenting these access tokens to resource server > for access to a protected resource, > * guidance for securely using OAuth 2.0, > * the ability to revoke access tokens, > * standardized format for security tokens encoded in a JSON format > (JSON Web Token, JWT), > * ways of using assertions with OAuth, and > * a dynamic client registration protocol. > > The working group also developed security schemes for presenting > authorization tokens to access a protected resource. This led to the > publication of the bearer token, as well as work that remains to be > completed on proof-of-possession and token exchange. > > The ongoing standardization effort within the OAuth working group will > focus on enhancing interoperability and functionality of OAuth > deployments, such as a standard for a token introspection service and > standards for additional security of OAuth requests. > > ----- > > Feedback appreciated. > > Ciao > Hannes & Derek > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > -- > > [image: Ping Identity logo] <https://www.pingidentity.com/> > > *Brian Campbell* > Portfolio Architect > > *@* > > bcampb...@pingidentity.com > > [image: phone] > > +1 720.317.2061 > > Connect with us… > > [image: twitter logo] <https://twitter.com/pingidentity>[image: youtube > logo] <https://www.youtube.com/user/PingIdentityTV>[image: LinkedIn > logo]<https://www.linkedin.com/company/21870>[image: > Facebook logo] <https://www.facebook.com/pingidentitypage>[image: Google+ > logo] <https://plus.google.com/u/0/114266977739397708540>[image: > slideshare logo] <http://www.slideshare.net/PingIdentity>[image: > flipboard logo] <http://flip.it/vjBF7>[image: rss feed > icon]<https://www.pingidentity.com/blogs/> > > [image: Register for Cloud Identity Summit 2014 | Modern Identity > Revolution | 19–23 July, 2014 | Monterey, > CA]<https://www.cloudidentitysummit.com/> > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > 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
