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]> 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 > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
