Right, I read that as text for describing the examples and not for describing requirements.
The token itself doesn’t have to be signed at all. — Justin > On Nov 25, 2015, at 1:05 PM, Phil Hunt <phil.h...@oracle.com> wrote: > > Ok. Well this was requested by Kathleen because of this paragraph in Sec 6.… > > To simplify the subsequent description we assume in the PoP architecture > that the token itself is digitally signed by the authorization server > and therefore cannot be modified. > > Please > Phil > > @independentid > www.independentid.com <http://www.independentid.com/>phil.h...@oracle.com > <mailto:phil.h...@oracle.com> >> On Nov 25, 2015, at 9:33 AM, Justin Richer <jric...@mit.edu >> <mailto:jric...@mit.edu>> wrote: >> >> The token doesn’t have to be signed and the client doesn’t have to verify >> the signature on the token. That’s not PoP. The request has to be signed in >> a way that includes the token. The token itself can still be opaque. The >> *key* material can’t be opaque to the client, but the *token* material still >> is. >> >> I agree with Brian that this statement is misleading. >> >> The examples use a signed token but that is absolutely not a requirement. >> Maybe the examples shouldn’t all use one style. >> >> What’s most difficult about this particular spec is that it’s very >> hand-wavy, saying “this is kinda a thing that kinda works like this” without >> saying how to actually do it. I’m honestly not sure it’s worth publishing as >> an RFC in its own right but I’m not going to stand in its way. >> >> — Justin >> >>> On Nov 25, 2015, at 12:14 PM, Brian Campbell <bcampb...@pingidentity.com >>> <mailto:bcampb...@pingidentity.com>> wrote: >>> >>> Where does it say that? >>> >>> >>> >>> On Wed, Nov 25, 2015 at 8:44 AM, Phil Hunt <phil.h...@oracle.com >>> <mailto:phil.h...@oracle.com>> 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 <bcampb...@pingidentity.com >>> <mailto:bcampb...@pingidentity.com>> 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 <phil.h...@oracle.com >>>> <mailto:phil.h...@oracle.com>> 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/> >>>> phil.h...@oracle.com <mailto:phil.h...@oracle.com> >>>> >>>> > On Nov 24, 2015, at 12:05 PM, internet-dra...@ietf.org >>>> > <mailto:internet-dra...@ietf.org> 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 >>>> > OAuth@ietf.org <mailto:OAuth@ietf.org> >>>> > https://www.ietf.org/mailman/listinfo/oauth >>>> > <https://www.ietf.org/mailman/listinfo/oauth> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>> >>>> >>>> >>>> -- >>>> <https://www.pingidentity.com/> >>>> Brian Campbell >>>> Distinguished Engineer >>>> Ping Identity >>>> @ bcampb...@pingidentity.com <mailto:bcampb...@pingidentity.com> >>>> +1 720.317.2061 <tel:%2B1%20720.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/> >>> >>> >>> -- >>> <https://www.pingidentity.com/> >>> Brian Campbell >>> Distinguished Engineer >>> Ping Identity >>> @ bcampb...@pingidentity.com <mailto:bcampb...@pingidentity.com> >>> +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 >>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://www.ietf.org/mailman/listinfo/oauth> >> >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
