The token is opaque to the client.  It’s format is a matter between the RS and 
the AS. 

Where do we require the client verify the token?    The RS is the only party 
that needs to verify the access token.

The information that the client needs about the token is in additional 
meta-data delivered with but not in the AT.

I agree with Brian that is wrong on two counts.

1) the token is opaque to the client.
2) one method of delivering the key to the RS is in a signed JWT.  It is 
however also possible (if not ideal) for the AT to be a reference, and 
introspected by the RS to get the key.

So 
"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 are also opaque to OAuth 2.0 
clients but may be parsed and verified, or introspected by OAuth 2.0 Resource 
Servers. When token endpoints issue “PoP” tokens they provide the OAuth Client 
additional parameters with information on what key material to use for the 
proof.”

Or given that they are both opaque that part of the statement could be dropped.

John B. 


> On Nov 25, 2015, at 12:44 PM, Phil Hunt <[email protected]> wrote:
> 
> 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 <[email protected] 
> <mailto:[email protected]>> 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 <[email protected] 
>> <mailto:[email protected]>> 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 <http://www.independentid.com/>
>> [email protected] <mailto:[email protected]>
>> 
>> > On Nov 24, 2015, at 12:05 PM, [email protected] 
>> > <mailto:[email protected]> 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/ 
>> > <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 
>> > <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 
>> > <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 
>> > <http://tools.ietf.org/>.
>> >
>> > Internet-Drafts are also available by anonymous FTP at:
>> > ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
>> >
>> > _______________________________________________
>> > OAuth mailing list
>> > [email protected] <mailto:[email protected]>
>> > https://www.ietf.org/mailman/listinfo/oauth 
>> > <https://www.ietf.org/mailman/listinfo/oauth>
>> 
>> _______________________________________________
>> OAuth mailing list
>> [email protected] <mailto:[email protected]>
>> https://www.ietf.org/mailman/listinfo/oauth 
>> <https://www.ietf.org/mailman/listinfo/oauth>
>> 
>> 
>> 
>> -- 
>>  <https://www.pingidentity.com/>                             
>> Brian Campbell
>> Distinguished Engineer
>> Ping Identity
>> @    [email protected] <mailto:[email protected]>
>>      +1 720.317.2061
>>      @pingidentity
>> Connect with us!
>>  <https://www.pingidentity.com/> <https://www.pingidentity.com/>
>>  <https://ping.force.com/Support/PingIdentityCommunityHome> 
>> <https://ping.force.com/Support/PingIdentityCommunityHome> 
>> <http://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>
>>   <https://twitter.com/pingidentity>  
>> <https://www.youtube.com/user/PingIdentityTV>  
>> <https://www.linkedin.com/company/21870>  
>> <https://www.facebook.com/pingidentitypage>  
>> <https://plus.google.com/u/0/114266977739397708540>  
>> <http://www.slideshare.net/PingIdentity>  <http://flip.it/vjBF7>  
>> <https://www.pingidentity.com/blogs/>_______________________________________________
> OAuth mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to