Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

[Chuck Mortimore <[e-mail]>]

"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
<[e-mail]>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:[e-mail] <[e-mail]>] *On
> Behalf Of *Phil Hunt
> *Sent:* Wednesday, May 14, 2014 8:32 AM
> *To:* Brian Campbell
> *Cc:* [e-mail]
> *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 <[e-mail]>
> 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 <
> [e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> --
>
> [image: Ping Identity logo] <https://www.pingidentity.com/>
>
> *Brian Campbell*
> Portfolio Architect
>
> *@*
>
> [e-mail]
>
> [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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing [e-mail]://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> _______________________________________________
> OAuth mailing [e-mail]://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>