Justin, I was wondering why you put in the second sentence in bold. :-)
I’m not sure which one you want to take out. Would you post the text exactly as you would like it? Thanks, Phil @independentid www.independentid.com [email protected] > On Dec 1, 2015, at 11:21 AM, Justin Richer <[email protected]> wrote: > > 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] >> <mailto:[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 >>> <https://www.ietf.org/mailman/listinfo/oauth> >> >> _______________________________________________ >> 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
