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

[John Bradley <[e-mail]>]

I have been told that DT has a implementation and I know Google is using it for the apps they publish on iOS and perhaps other places, though they may use pre Draft parameter names currently.

There are some others I have talked to, but I will need to get there permission to disclose there names.

John B.
On May 14, 2014, at 11:59 PM, Brian Campbell <[e-mail]> wrote:

> I did an implementation of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 last week. We are seeing growing demand for some kind of solution to the code callback interception attack. The industry needs a well documented standard solution.
> 
> 
> On Wed, May 14, 2014 at 3:16 PM, Anthony Nadalin <[e-mail]> wrote:
> Please list the implementstions
> 
>  
> 
> From: OAuth [mailto:[e-mail]] On Behalf Of John Bradley
> Sent: Wednesday, May 14, 2014 10:59 AM
> 
> 
> To: Brian Campbell
> Cc: [e-mail]
> Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering
> 
>  
> 
> I know a number of people implementing
> 
> 
> 
> 
> http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03
> 
>  
> 
> Having it on a RFC track may make sense. 
> 
>  
> 
> I remain to be convinced that a4c ads anything other than confusion. 
> 
>  
> 
> If the WG wants to take it up it should be aligned with Connect.  I think there are more important things to spend time on. 
> 
>  
> 
> 
> Sent from my iPhone
> 
> 
> On May 14, 2014, at 2:24 PM, 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
> 
> 
> 
> 
> --
> 
> 
> 
> Brian Campbell
> Portfolio Architect
> 
> @
> 
> [e-mail]
> 
> 
> 
> +1 720.317.2061
> 
> Connect with us…
> 
> 
> 
> 
> 
>  
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
> 
>