Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt

[Kathleen Moriarty <[e-mail]>]

Thanks, guys.  If we are all okay, I'll start the last call once the new
draft is posted.  I need to get them started by sometime tomorrow to keep
them on the telechat in 2 weeks.

Thanks,
Kathleen

On Tue, Dec 1, 2015 at 5:28 PM, John Bradley <[e-mail]> wrote:

> That looks good to me.
>
> On Dec 1, 2015, at 4:21 PM, Justin Richer <[e-mail]> 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 <[e-mail]> 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
> [e-mail]
>
> On Dec 1, 2015, at 10:35 AM, Phil Hunt <[e-mail]> wrote:
>
> Thanks Justin. Your tweaks look good to me.
>
> Phil
>
> @independentid
> www.independentid.com
> [e-mail]
>
> On Dec 1, 2015, at 10:28 AM, Kathleen Moriarty <
> [e-mail]> wrote:
>
> The changes work for me, thanks.
>
> On Tue, Dec 1, 2015 at 1:27 PM, Justin Richer <[e-mail]> 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 <[e-mail]> 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
>> [e-mail]
>>
>> On Nov 25, 2015, at 2:19 PM, Kathleen Moriarty <
>> [e-mail]> wrote:
>>
>>
>>
>> On Wed, Nov 25, 2015 at 3:58 PM, John Bradley <[e-mail]> 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 <[e-mail]> 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 <
>>> [e-mail]> wrote:
>>>
>>> Hi,
>>>
>>> Sent from my iPhone
>>>
>>> On Nov 25, 2015, at 3:20 PM, John Bradley <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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:
>>>
>>>
>>>
>>> [image:
>>> http://www.websequencediagrams.com/cgi-bin/cdraw?lz=cGFydGljaXBhbnQgQ2xpZW50IGFzIEMKAAwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYAIQZBUwA7DVByb3RlY3RlZABICmFzIFJTCgoKClJPLS0-QzogR28gZ2V0IG15IHIAbwcKQy0tPlJPOiBSZWRpcmVjdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHBQpBUwAqEwAVBwBrCEhhbmQAKQcAPAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4GVG9rZW4gcmVxdWVzdCAoADAFKQpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBUMAPAgmIEsAEAtlbHMAgTcIAE8pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kCgpDLT5SUzogUgCBUQdpbmNsdWRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMARAZjaGVjawCCAAdzaWduYXR1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIYBWludHJvc3BlY3RpbwBiBkFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVibGljIG9yIHNoYXJlZCkAgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQthAIQoBgCCUAUAgX4OAIQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiByZXR1cm4AhicJ&s=modern-blue]
>>>
>>>
>>>
>>> (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-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 <[e-mail]> 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
>>> [e-mail]
>>>
>>> On Nov 25, 2015, at 10:48 AM, Brian Campbell <[e-mail]>
>>> 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 <[e-mail]> 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 <[e-mail]> 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
>>>> [e-mail]
>>>>
>>>> On Nov 25, 2015, at 9:33 AM, Justin Richer <[e-mail]> 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 <
>>>> [e-mail]> wrote:
>>>>
>>>> Where does it say that?
>>>>
>>>>
>>>>
>>>> On Wed, Nov 25, 2015 at 8:44 AM, Phil Hunt <[e-mail]>
>>>> 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 <[e-mail]>
>>>>> 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 <[e-mail]>
>>>>> 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
>>>>>> [e-mail]
>>>>>>
>>>>>> > On Nov 24, 2015, at 12:05 PM, [e-mail] 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/
>>>>>> >
>>>>>> > There's also a htmlized version available at:
>>>>>> > 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
>>>>>> >
>>>>>> >
>>>>>> > 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
>>>>>> .
>>>>>> >
>>>>>> > Internet-Drafts are also available by anonymous FTP at:
>>>>>> > ftp://ftp.ietf.org/internet-drafts/
>>>>>> >
>>>>>> > _______________________________________________
>>>>>> > OAuth mailing list
>>>>>> > [e-mail]
>>>>>> > https://www.ietf.org/mailman/listinfo/oauth
>>>>>>
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> [image: Ping Identity logo] <https://www.pingidentity.com/>
>>>>> Brian Campbell
>>>>> Distinguished Engineer
>>>>> Ping Identity
>>>>> @ [e-mail] [image: phone] +1 720.317.2061 [image:
>>>>> twitter] @pingidentity Connect with us!
>>>>> <https://www.pingidentity.com/>[image: pingidentity.com]
>>>>> <https://www.pingidentity.com/>
>>>>> <https://ping.force.com/Support/PingIdentityCommunityHome>[image:
>>>>> pingidentity.com]
>>>>> <https://ping.force.com/Support/PingIdentityCommunityHome>
>>>>> [image: twitter logo]
>>>>> <http://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm> [image:
>>>>> twitter logo] <https://twitter.com/pingidentity> [image: youtube logo]
>>>>> <https://www.youtube.com/user/PingIdentityTV> [image: LinkedIn logo]
>>>>> <https://www.linkedin.com/company/21870> [image: Facebook logo]
>>>>> <https://www.facebook.com/pingidentitypage> [image: Google+ logo]
>>>>> <https://plus.google.com/u/0/114266977739397708540> [image:
>>>>> slideshare logo] <http://www.slideshare.net/PingIdentity> [image:
>>>>> flipboard logo] <http://flip.it/vjBF7> [image: rss feed icon]
>>>>> <https://www.pingidentity.com/blogs/>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> [image: Ping Identity logo] <https://www.pingidentity.com/>
>>>> Brian Campbell
>>>> Distinguished Engineer
>>>> Ping Identity
>>>> @ [e-mail] [image: phone] +1 720.317.2061 [image:
>>>> twitter] @pingidentity Connect with us!
>>>> <https://www.pingidentity.com/>[image: pingidentity.com]
>>>> <https://www.pingidentity.com/>
>>>> <https://ping.force.com/Support/PingIdentityCommunityHome>[image:
>>>> pingidentity.com]
>>>> <https://ping.force.com/Support/PingIdentityCommunityHome>
>>>> [image: twitter logo]
>>>> <http://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm> [image:
>>>> twitter logo] <https://twitter.com/pingidentity> [image: youtube logo]
>>>> <https://www.youtube.com/user/PingIdentityTV> [image: LinkedIn logo]
>>>> <https://www.linkedin.com/company/21870> [image: Facebook logo]
>>>> <https://www.facebook.com/pingidentitypage> [image: Google+ logo]
>>>> <https://plus.google.com/u/0/114266977739397708540> [image: slideshare
>>>> logo] <http://www.slideshare.net/PingIdentity> [image: flipboard logo]
>>>> <http://flip.it/vjBF7> [image: rss feed icon]
>>>> <https://www.pingidentity.com/blogs/>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> [image: Ping Identity logo] <https://www.pingidentity.com/>
>>> Brian Campbell
>>> Distinguished Engineer
>>> Ping Identity
>>> @ [e-mail] [image: phone] +1 720.317.2061 [image:
>>> twitter] @pingidentity Connect with us!
>>> <https://www.pingidentity.com/>[image: pingidentity.com]
>>> <https://www.pingidentity.com/>
>>> <https://ping.force.com/Support/PingIdentityCommunityHome>[image:
>>> pingidentity.com]
>>> <https://ping.force.com/Support/PingIdentityCommunityHome>
>>> [image: twitter logo]
>>> <http://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm> [image:
>>> twitter logo] <https://twitter.com/pingidentity> [image: youtube logo]
>>> <https://www.youtube.com/user/PingIdentityTV> [image: LinkedIn logo]
>>> <https://www.linkedin.com/company/21870> [image: Facebook logo]
>>> <https://www.facebook.com/pingidentitypage> [image: Google+ logo]
>>> <https://plus.google.com/u/0/114266977739397708540> [image: slideshare
>>> logo] <http://www.slideshare.net/PingIdentity> [image: flipboard logo]
>>> <http://flip.it/vjBF7> [image: rss feed icon]
>>> <https://www.pingidentity.com/blogs/>
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>
>
> --
>
> Best regards,
> Kathleen
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>


-- 

Best regards,
Kathleen