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 phil.h...@oracle.com On May 14, 2014, at 10:23 AM, George Fletcher <gffle...@aol.com> 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 <jric...@mit.edu> 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 <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 >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Brian Campbell >>>> Portfolio Architect >>>> @ bcampb...@pingidentity.com >>>> +1 720.317.2061 >>>> Connect with us… >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > -- > <XeC.html> > _______________________________________________ > 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
