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

[Phil Hunt <[e-mail]>]

This is not an authentication mechanism - it is a method for providing end-user authentication information to client applications.  I will publish a revised draft shortly. 

Phil

@independentid
www.independentid.com
[e-mail]



On May 14, 2014, at 10:23 AM, George Fletcher <[e-mail]> wrote:

> I also would like to see the WG not focus on another authentication mechanism and instead look at work like Brian suggested.
> 
> Thanks,
> George
> 
> On 5/14/14, 11:41 AM, Chuck Mortimore wrote:
>> Agree with Brian and Justin here.   Work is already covered in Connect
>> 
>> - cmort
>> 
>> On May 14, 2014, at 8:39 AM, Justin Richer <[e-mail]> wrote:
>> 
>>> I agree with Brian and object to the Authentication work item. I think there’s limited interest and utility in such a draft, especially now that OpenID Connect has been published and its core authentication capabilities are identical to what was called for in the other draft a year ago (a similarity, I’ll add, which was noted at the time). 
>>> 
>>>  — Justin
>>> 
>>> On May 14, 2014, at 8:24 AM, 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
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> -- 
> <XeC.html>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth