Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt

[Phil Hunt <[e-mail]>]

Except that later on we require the token be signed and the client verify that signed token. IOW mutual pop. 

Phil

> On Nov 25, 2015, at 07:30, Brian Campbell <[e-mail]> wrote:
> 
> Looking at the diff I noticed the following new text, which seems to conflate bearer/PoP and opaqueness to the client. A client demonstrating proof-of-possession of some key is orthogonal to the client being able to parse and understand the access token itself. 
>  
> "In contrast to bearer tokens [RFC6750] which call for tokens that are opaque to OAuth 2.0 clients, this specification defines the requirements for proof-of-possession ("PoP") tokens that may be parsed and verified by OAuth 2.0 clients and relying parties."
> 
>> On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt <[e-mail]> wrote:
>> This draft addresses review comments from Kathleen and Erik raised since the last draft.
>> 
>> It may not include some of the discussion from yesterday/today.  I will add that as the group decides.
>> 
>> Cheers,
>> 
>> Phil
>> 
>> @independentid
>> www.independentid.com
>> [e-mail]
>> 
>> > On Nov 24, 2015, at 12:05 PM, [e-mail] wrote:
>> >
>> >
>> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> > This draft is a work item of the Web Authorization Protocol Working Group of the IETF.
>> >
>> >        Title           : OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
>> >        Authors         : Phil Hunt
>> >                          Justin Richer
>> >                          William Mills
>> >                          Prateek Mishra
>> >                          Hannes Tschofenig
>> >       Filename        : draft-ietf-oauth-pop-architecture-06.txt
>> >       Pages           : 23
>> >       Date            : 2015-11-24
>> >
>> > Abstract:
>> >   The OAuth 2.0 bearer token specification, as defined in RFC 6750,
>> >   allows any party in possession of a bearer token (a "bearer") to get
>> >   access to the associated resources (without demonstrating possession
>> >   of a cryptographic key).  To prevent misuse, bearer tokens must be
>> >   protected from disclosure in transit and at rest.
>> >
>> >   Some scenarios demand additional security protection whereby a client
>> >   needs to demonstrate possession of cryptographic keying material when
>> >   accessing a protected resource.  This document motivates the
>> >   development of the OAuth 2.0 proof-of-possession security mechanism.
>> >
>> >
>> > The IETF datatracker status page for this draft is:
>> > https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/
>> >
>> > There's also a htmlized version available at:
>> > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-06
>> >
>> > A diff from the previous version is available at:
>> > https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-pop-architecture-06
>> >
>> >
>> > Please note that it may take a couple of minutes from the time of submission
>> > until the htmlized version and diff are available at tools.ietf.org.
>> >
>> > Internet-Drafts are also available by anonymous FTP at:
>> > ftp://ftp.ietf.org/internet-drafts/
>> >
>> > _______________________________________________
>> > OAuth mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/oauth
>> 
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> 
> -- 
>  				
> Brian Campbell
> Distinguished Engineer
> Ping Identity
> @	[e-mail]
> 	+1 720.317.2061
> 	@pingidentity
> Connect with us!
> 
> 
>