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

[Paul Madsen <[e-mail]>]

Phil, neither is Connect an authentication mechanism, it (and SAML, 
WS-fed etc) is also a 'method for providing end-user authentication 
information to client applications'

We don't need a Connect--

paul
On 5/14/14, 1:29 PM, Phil Hunt wrote:
> 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 <http://www.independentid.com>
> [e-mail] <mailto:[e-mail]>
>
>
>
> On May 14, 2014, at 10:23 AM, George Fletcher <[e-mail] 
> <mailto:[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] 
>>> <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[e-mail]>
>>>>>     https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> Ping Identity logo <https://www.pingidentity.com/> 	
>>>>> Brian Campbell
>>>>> Portfolio Architect
>>>>> @ 	[e-mail] <mailto:[e-mail]>
>>>>> phone 	[phone]
>>>>> Connect with us...
>>>>> twitter logo <https://twitter.com/pingidentity> youtube logo 
>>>>> <https://www.youtube.com/user/PingIdentityTV> LinkedIn logo 
>>>>> <https://www.linkedin.com/company/21870> Facebook logo 
>>>>> <https://www.facebook.com/pingidentitypage> Google+ logo 
>>>>> <https://plus.google.com/u/0/114266977739397708540> slideshare 
>>>>> logo <http://www.slideshare.net/PingIdentity> flipboard logo 
>>>>> <http://flip.it/vjBF7> rss feed icon 
>>>>> <https://www.pingidentity.com/blogs/>
>>>>>
>>>>> Register for Cloud Identity Summit 2014 | Modern Identity 
>>>>> Revolution | 19--23 July, 2014 | Monterey, CA 
>>>>> <https://www.cloudidentitysummit.com/>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [e-mail] <mailto:[e-mail]>
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> -- 
>> <XeC.html> <http://connect.me/gffletch>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth