The only actual requirement is opacity. Section 6 should be more clearly called out as an example instead, which is what it is.
Perhaps we should also re-state that access tokens remain opaque to the client in the introductory text. — Justin > On Nov 25, 2015, at 3:19 PM, Phil Hunt <[email protected]> wrote: > > Thats not what I am on about. > > Kathleen objected to the signed requirement in sec 6 without making it clear > in sec 5. > > We can't have it both ways. Be both opaque and signed for the client to > verify. > > If I restore the requirements than the threat mitigation assumption of signed > tokens must also be removed. > > Phil > > On Nov 25, 2015, at 12:02, John Bradley <[email protected] > <mailto:[email protected]>> wrote: > >> 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] >>> <mailto:[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] <mailto:[email protected]> >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://www.ietf.org/mailman/listinfo/oauth> >> > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
