The current text of 6 has. Alternatively, the content of the token could be passed by reference rather than by value (requiring a separate message exchange to resolve the reference to the token content).
The rest of 6 is an example of using the signed method. not the only method. > On Nov 25, 2015, at 5:31 PM, John Bradley <[email protected]> wrote: > > Yes all access tokens bearer or PoP are audienced to the RS, Integrity > protected in a way the RS can verify, and if required encrypted to the RS. > > I would guess that a majority of deployments I know of want introspection or > encrypted AT to protect the confidentiality of the attributes passed in the > access token. > There is commonly user and or role info that they want to protect. If PoP > required the tokens to be readable/verifiable by the client then it would be > a non starter for privacy reasons lots of places. > > John B. > > >> On Nov 25, 2015, at 5:21 PM, Justin Richer <[email protected] >> <mailto:[email protected]>> wrote: >> >> 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] >>> <mailto:[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] <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
