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]> 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]> 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]> >>> 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]> 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 >>>> [email protected] >>>> >>>> > On Nov 24, 2015, at 12:05 PM, [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/ >>>> > >>>> > 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 >>>> > [email protected] >>>> > https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> -- >>> >>> Brian Campbell >>> Distinguished Engineer >>> Ping Identity >>> @ [email protected] >>> +1 720.317.2061 >>> @pingidentity >>> Connect with us! >>> >>> >>> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
