Thanks Justin. Your tweaks look good to me. Phil
@independentid www.independentid.com [email protected] > On Dec 1, 2015, at 10:28 AM, Kathleen Moriarty > <[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] https://www.ietf.org/mailman/listinfo/oauth
