You’ve got “The token remains opaque to the client” in there twice now. I had cut out the middle part the first sentence in the second paragraph below, but that was hard to highlight. If you take my text as-is that’s what I meant for the edited form.
Thanks — Justin > On Dec 1, 2015, at 2:18 PM, Phil Hunt <[email protected]> wrote: > > Including Justin’s revision: > > A large range of threats can be mitigated by protecting the content > of the token, for example using a digital signature or a keyed > message digest. 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). > > To simplify discussion in the following examples, we assume that the > token itself is integrity protected by the authorization server and > the token remains opaque to the client. The token itself cannot be > modified by the client, either due to cryptographic protection (such > as signature or encryption) or the use of a reference value with > sufficient entropy and associated secure lookup. The token remains > opaque to the client. These are characteristics shared with bearer > tokens and more information on best practices can be found in > [RFC6819] and in the security considerations section of [RFC6750]. > > Phil > > @independentid > www.independentid.com <http://www.independentid.com/>[email protected] > <mailto:[email protected]> >> On Dec 1, 2015, at 10:35 AM, Phil Hunt <[email protected] >> <mailto:[email protected]>> wrote: >> >> Thanks Justin. Your tweaks look good to me. >> >> Phil >> >> @independentid >> www.independentid.com <http://www.independentid.com/>[email protected] >> <mailto:[email protected]> >>> On Dec 1, 2015, at 10:28 AM, Kathleen Moriarty >>> <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> The changes work for me, thanks. >>> >>> On Tue, Dec 1, 2015 at 1:27 PM, Justin Richer <[email protected] >>> <mailto:[email protected]>> wrote: >>> That’s much better. I would also suggest that a few edits to hammer home >>> that this is an example >>> >>>> A large range of threats can be mitigated by protecting the content >>>> of the token, for example using a digital signature or a keyed >>>> message digest. 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). To >>>> simplify discussion in the following example we assume >>>> that the token itself […] >>>> cannot be modified by the client, either due to cryptographic >>>> protection (such as signature or encryption) or use of a reference >>>> value with sufficient entropy and associated secure lookup. The token >>>> remains opaque to the client. >>>> These >>>> are characteristics shared with bearer tokens and more information on >>>> best practices can be found in [RFC6819] and in the security >>>> considerations section of [RFC6750]. >>> >>> That’s really what’s going on by my read. Thoughts? >>> >>> — Justin >>> >>>> On Dec 1, 2015, at 1:08 PM, Phil Hunt <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> I’ve reviewed the comments from John, Justin and Kathleen. As suggested, I >>>> plan to remove the erroneous first paragraph in section 5 (draft 06). >>>> >>>> Combining the comments from this thread about sec 6, here is the proposed >>>> new first paragraph: >>>> >>>> A large range of threats can be mitigated by protecting the content >>>> of the token, for example using a digital signature or a keyed >>>> message digest. 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). To >>>> simplify the subsequent description we assume in the PoP architecture >>>> that the token itself is integrity protected by the authorization >>>> server and the token remains opaque to the client. The token itself >>>> cannot be modified by the client, either due to cryptographic >>>> protection (such as signature or encryption) or use of a reference >>>> value with sufficient entropy and associated secure lookup. These >>>> are characteristics shared with bearer tokens and more information on >>>> best practices can be found in [RFC6819] and in the security >>>> considerations section of [RFC6750]. >>>> If this looks good to the group, I’ll post draft 7 this afternoon >>>> (pacific). >>>> >>>> Thanks, >>>> >>>> Phil >>>> >>>> @independentid >>>> www.independentid.com <http://www.independentid.com/>[email protected] >>>> <mailto:[email protected]> >>>>> On Nov 25, 2015, at 2:19 PM, Kathleen Moriarty >>>>> <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> >>>>> >>>>> On Wed, Nov 25, 2015 at 3:58 PM, John Bradley <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> I am fine with that, however saying integrity protected, may be better >>>>> than signed. May people will argue that HMAC or encryption with sender >>>>> verification is not signature. >>>>> >>>>> Good point, I also prefer integrity protected. Are we all good with this >>>>> now? I'd like to look at a diff to make sure after following the thread. >>>>> >>>>> Thanks! >>>>> Kathleen >>>>> >>>>> >>>>> However they are perfectly valid. >>>>> >>>>> >>>>>> On Nov 25, 2015, at 5:53 PM, Justin Richer <[email protected] >>>>>> <mailto:[email protected]>> wrote: >>>>>> >>>>>> The requirement is not that signed JWTs be used, it’s that unsigned JWTs >>>>>> not be used on their own. Reference tokens and encrypted JWTs are also >>>>>> valid, as are other signed formats like SAML assertions or even a COSE >>>>>> Token (if it’s encoded to HTTP friendliness). >>>>>> >>>>>> My recommendation: >>>>>> >>>>>> Remove the erroneous requirement text from section 5 and restore to >>>>>> previous version. >>>>>> >>>>>> Amend the text in section 6 from: >>>>>> >>>>>> 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. >>>>>> >>>>>> >>>>>> To: >>>>>> >>>>>> In all such cases, the token remains opaque to the client. To >>>>>> simplify the subsequent example and description we assume in the PoP >>>>>> architecture >>>>>> that the token itself cannot be modified by the client, either due to >>>>>> cryptographic protection (such as signature or encryption) or use of >>>>>> a reference value with sufficient entropy and associated secure >>>>>> lookup. >>>>>> These are characteristics shared with bearer tokens and more >>>>>> information >>>>>> on best practices can be found in [[RFC6819]] and in the security >>>>>> considerations section of [[RFC6750]]. >>>>>> >>>>>> >>>>>> — Justin >>>>>> >>>>>>> On Nov 25, 2015, at 3:39 PM, Kathleen Moriarty >>>>>>> <[email protected] >>>>>>> <mailto:[email protected]>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Sent from my iPhone >>>>>>> >>>>>>> On Nov 25, 2015, at 3:20 PM, John Bradley <[email protected] >>>>>>> <mailto:[email protected]>> wrote: >>>>>>> >>>>>>>> Tokens are signed or the information is otherwise integrity protected >>>>>>>> between the AS and the RS. >>>>>>>> >>>>>>>> I suspect Kathleen is concerned about the key getting modified in >>>>>>>> transit. >>>>>>>> That needs to be protected against, but there is more than one way to >>>>>>>> do that. >>>>>>> >>>>>>> Phil is correct. I was looking for consistency between the sections >>>>>>> since they related to each other. If there is a security risk or >>>>>>> consideration, that needs to be explicitly called out as a concern such >>>>>>> as a key being modified in transit. If there are options to protect >>>>>>> against that, those would ideally be required or would have warnings. >>>>>>>> >>>>>>>> So sending the public key in a unsigned JWT access token would be >>>>>>>> immensely stupid, not just for PoP but for scopes and everything else. >>>>>>> >>>>>>> Good, easy to require then. >>>>>>> >>>>>>> Thanks, >>>>>>> Kathleen >>>>>>>> >>>>>>>> In OAuth 2 all tokens need to be integrity protected between the AS >>>>>>>> and RS. >>>>>>>> That can be via signature, by having a reference with sufficient >>>>>>>> entropy and secure introspection or database lookup. >>>>>>>> >>>>>>>> I think that is a OAuth 2 security consideration. We are adding a >>>>>>>> additional confirmation claim to the existing information that needs >>>>>>>> to be protected the same as the rest. >>>>>>>> >>>>>>>> John B. >>>>>>>> >>>>>>>> >>>>>>>>> On Nov 25, 2015, at 4:38 PM, Phil Hunt <[email protected] >>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>> >>>>>>>>> <editors hat> >>>>>>>>> If there is agreement that tokens are opaque then the requirement >>>>>>>>> that tokens be signed must be removed from the threat mitigation >>>>>>>>> requirements. >>>>>>>>> >>>>>>>>> And the paragraph in sec 5 that brian was concerned about be >>>>>>>>> restored. >>>>>>>>> >>>>>>>>> Phil >>>>>>>>> >>>>>>>>> On Nov 25, 2015, at 11:24, Justin Richer <[email protected] >>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>> >>>>>>>>>> It is still end to end authentication with opaque tokens — since all >>>>>>>>>> OAuth tokens, including PoP tokens, have always been intended to be >>>>>>>>>> opaque to the client. That hasn’t changed and that isn’t the intent >>>>>>>>>> of this document. If that’s how people are reading it then we need >>>>>>>>>> to pull it back and rewrite it so that’s not the case. >>>>>>>>>> >>>>>>>>>> The client gets a token that has two parts: the token and the key. >>>>>>>>>> The token is analogous to the access_token we have today and would >>>>>>>>>> come out of the server in the same field. The key is handed to the >>>>>>>>>> client alongside the token or registered by the client during the >>>>>>>>>> token request. Either way there’s an association between the two but >>>>>>>>>> it’s not the same association as a public/private keypair. >>>>>>>>>> >>>>>>>>>> It’s possible to sign the token itself, but the client doesn’t care. >>>>>>>>>> It sends the token and signs the HTTP request to the RS whether the >>>>>>>>>> token is signed, unsigned, hex blob, encrypted, or anything else. >>>>>>>>>> The same series of options are available as with bearer tokens. PoP >>>>>>>>>> tokens have never, ever been intended to be anything but opaque to >>>>>>>>>> the client. >>>>>>>>>> >>>>>>>>>> The token can’t be opaque to the RS, which has to figure out what >>>>>>>>>> key to use to check the message signature. But we’ve got options >>>>>>>>>> there, like the embedded key in a JWT from Mike’s draft, or doing >>>>>>>>>> introspection to get the key (from an extension that hasn’t been >>>>>>>>>> written yet), or simply looking it up in the same database because >>>>>>>>>> the RS and the AS are in the same box. Does this >>>>>>>>>> structure/service/database choice sound familiar? It should, it’s >>>>>>>>>> the same as bearer tokens. This is also how the RS gets information >>>>>>>>>> like which scopes are associated with the token, if it’s expired, >>>>>>>>>> and all that. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> So here’s how I see it going on the wire: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> (I just wrote this up so there are probably holes. Here’s the source >>>>>>>>>> if anyone wants to tweak it: >>>>>>>>>> http://www.websequencediagrams.com/?lz=cGFydGljaXBhbnQgQ2xpZW50IGFzIEMKAAwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYAIQZBUwA7DVByb3RlY3RlZABICmFzIFJTCgoKClJPLS0 >>>>>>>>>> >>>>>>>>>> <http://www.websequencediagrams.com/?lz=cGFydGljaXBhbnQgQ2xpZW50IGFzIEMKAAwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYAIQZBUwA7DVByb3RlY3RlZABICmFzIFJTCgoKClJPLS0>-QzogR28gZ2V0IG15IHIAbwcKQy0tPlJPOiBSZWRpcmVjdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHBQpBUwAqEwAVBwBrCEhhbmQAKQcAPAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4GVG9rZW4gcmVxdWVzdCAoADAFKQpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBUMAPAgmIEsAEAtlbHMAgTcIAE8pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kCgpDLT5SUzogUgCBUQdpbmNsdWRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMARAZjaGVjawCCAAdzaWduYXR1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIYBWludHJvc3BlY3RpbwBiBkFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVibGljIG9yIHNoYXJlZCkAgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQthAIQoBgCCUAUAgX4OAIQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiByZXR1cm4AhicJ&s=modern-blue >>>>>>>>>> ) >>>>>>>>>> >>>>>>>>>> The client is oblivious to the token just like always. This is >>>>>>>>>> intentional. The RS has the same options to figure out how to >>>>>>>>>> process the token. >>>>>>>>>> >>>>>>>>>> — Justin >>>>>>>>>> >>>>>>>>>>> On Nov 25, 2015, at 2:03 PM, Phil Hunt <[email protected] >>>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>>> >>>>>>>>>>> Folks, >>>>>>>>>>> >>>>>>>>>>> <editor hat> >>>>>>>>>>> I did not want to go here either. :-) >>>>>>>>>>> >>>>>>>>>>> I don’t read sec 6 as examples. I believe this may stem from the >>>>>>>>>>> pop-architecture documents having a dual role as both >>>>>>>>>>> “architecture” and “use-case”. Maybe we should clarify the purpose >>>>>>>>>>> of the document? >>>>>>>>>>> >>>>>>>>>>> I believe section 6 is talking about threat mitigation assumptions >>>>>>>>>>> based on the examples that need to be implemented. I am assuming >>>>>>>>>>> these are requirements that the other specifications SHOULD >>>>>>>>>>> implement. >>>>>>>>>>> >>>>>>>>>>> <personal hat> >>>>>>>>>>> I do not believe we have discussed Opaque PoP tokens and any >>>>>>>>>>> inherent risks because the client is not or is unable to validate >>>>>>>>>>> the authenticity of the token. Does this introduce the possibility >>>>>>>>>>> of a MITM attack where a client can be convinced to sign requests >>>>>>>>>>> for an attacker? >>>>>>>>>>> >>>>>>>>>>> If we want to include opaque PoP, I think we need to take a pause >>>>>>>>>>> and consider / discuss any threats here. >>>>>>>>>>> >>>>>>>>>>> I find the desire for opaque PoP tokens to be a bit contradictory. >>>>>>>>>>> If we’re saying we don’t want to trust TLS alone (e.g. because of >>>>>>>>>>> load-balancer termination), why would we then say, but we are >>>>>>>>>>> perfectly willing to accept it worked for the OAuth AS exchanges? >>>>>>>>>>> Maybe I was very wrong here, but my assumption all along is that >>>>>>>>>>> for PoP we’re talking about end-to-end authentication of all >>>>>>>>>>> parties except in the case of 3.3 where we simply want to protect >>>>>>>>>>> an access token over a non-TLS HTTP connection. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Phil >>>>>>>>>>> >>>>>>>>>>> @independentid >>>>>>>>>>> www.independentid.com >>>>>>>>>>> <http://www.independentid.com/>[email protected] >>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>> On Nov 25, 2015, at 10:48 AM, Brian Campbell >>>>>>>>>>>> <[email protected] <mailto:[email protected]>> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> While I can't say I disagree with the deeper existential questions >>>>>>>>>>>> about the draft that Justin raises, I was trying not to go there >>>>>>>>>>>> and rather just point out concerns with the newly added text. >>>>>>>>>>>> >>>>>>>>>>>> The text Phil cites from Sec 6 doesn't say the client must be able >>>>>>>>>>>> to parse and verify the token. It's an assumption to simplify the >>>>>>>>>>>> examples that follow and still the token is opaque to the client. >>>>>>>>>>>> I reread the whole draft (reluctantly) and there's nothing that >>>>>>>>>>>> says the token has to be non-opaque to the client. And it does >>>>>>>>>>>> talk about reference style tokens and encrypted tokens, both of >>>>>>>>>>>> which rely on the opaqueness to the client. >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Nov 25, 2015 at 11:27 AM, Justin Richer <[email protected] >>>>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>>>> 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 <[email protected] >>>>>>>>>>>>> <mailto:[email protected]>> 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/>[email protected] >>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>> On Nov 25, 2015, at 9:33 AM, Justin Richer <[email protected] >>>>>>>>>>>>>> <mailto:[email protected]>> 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 >>>>>>>>>>>>>>> <[email protected] >>>>>>>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Where does it say that? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Wed, Nov 25, 2015 at 8:44 AM, 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 <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 >>>>>>>>>>>>>>> @ [email protected] >>>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>>> +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/>_______________________________________________ >>>>>>>>>>>>>>> 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 <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/> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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] <mailto:[email protected]> >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Best regards, >>>>> Kathleen >>>>> _______________________________________________ >>>>> 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> >>> >>> >>> >>> >>> -- >>> >>> Best regards, >>> Kathleen >> >> _______________________________________________ >> OAuth mailing list >> [email protected] <mailto:[email protected]> >> 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
