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

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Wed, 25 November 2015 22:19 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 376131A8BC5 for <oauth@ietfa.amsl.com>; Wed, 25 Nov 2015 14:19:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JyLihEFbFzcM for <oauth@ietfa.amsl.com>; Wed, 25 Nov 2015 14:19:33 -0800 (PST)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35FBC1B317B for <oauth@ietf.org>; Wed, 25 Nov 2015 14:19:32 -0800 (PST)
Received: by wmuu63 with SMTP id u63so18723wmu.0 for <oauth@ietf.org>; Wed, 25 Nov 2015 14:19:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/nhUQ+iNWZtg243c7UuRODGQJ/8ThIliDwdav0Bn/YI=; b=XjRvhfPuKoQlNQAAKeYgP1w8gJEGaWsyPvYBKMbUsgHXzAcFecTxByeSW4mw/ouef+ eXozZMssSiEUQVlHxu/HiDpacFwHLKwqVJkPYq2S1cJZYV5Ga6KviYPp0HpLyar/v8CF GqPt5kv+Om9G1cT/GUSobLicVlog+Vg20SjctNmg9MxseVIQb8QPnTXxn4du6ggs+AMG m4zMQ/3CemFLDgOtK2y3L5mh3rjnVUh3UtO+v+ztZ4sa461c6AlCLi1C9MYxjjfSOqjL Lm8NV8NBfnn70HoAXf1Wt8ND7R3c9KBwFxsSKszKi6DQXRO42Uuq1S7LP2ACA6mmn3NB x70A==
MIME-Version: 1.0
X-Received: by 10.194.222.195 with SMTP id qo3mr3946555wjc.51.1448489970664; Wed, 25 Nov 2015 14:19:30 -0800 (PST)
Received: by 10.28.52.130 with HTTP; Wed, 25 Nov 2015 14:19:30 -0800 (PST)
In-Reply-To: <207E620F-97AA-4851-8776-2A7B1921D58A@ve7jtb.com>
References: <20151124200512.20833.28463.idtracker@ietfa.amsl.com> <F787FB76-5C8D-45F5-8A81-E430E75A0455@oracle.com> <CA+k3eCSeOyc2HMY+sK9rSjxkSAvNPWqwKyJNjDZAaCu2Stqk=w@mail.gmail.com> <16FAD3AC-CFB8-46D5-A12E-436E902EA439@oracle.com> <CA+k3eCT1+=2zysgbaKEmWCkQmsKyjr9KbghgmOVYUSC1qLfjbg@mail.gmail.com> <D8D36156-8BA6-43C5-8016-94A4CAE5FB45@mit.edu> <6015EE15-1FEE-43DC-930C-68ACAEDC083E@oracle.com> <38555799-721C-4A2F-AAAA-24D9B69EB72E@mit.edu> <CA+k3eCSJPCnawTjbByPcj+mmcK+vvQ_0Cxzs=24kT-irGETi7w@mail.gmail.com> <1AD1F44B-9837-4288-9997-5292F1DBE30E@oracle.com> <EABBA496-7916-413A-BFE7-65BD03528F01@mit.edu> <CAD8AAD1-5A94-4F78-86EC-4D0F6FF6E0FE@oracle.com> <9E20E73C-AC35-4E03-A011-119A32CD0BF1@ve7jtb.com> <7431079B-818C-46E9-8102-D193E49384B2@gmail.com> <638FA321-4DE1-467C-9B5C-3BEA0EC3EB0F@mit.edu> <207E620F-97AA-4851-8776-2A7B1921D58A@ve7jtb.com>
Date: Wed, 25 Nov 2015 17:19:30 -0500
Message-ID: <CAHbuEH6na4NELpMkZqy-+3GZ0xLXLtdoC=4taMWtnY-o3CyJkQ@mail.gmail.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
To: John Bradley <ve7jtb@ve7jtb.com>
Content-Type: multipart/alternative; boundary="001a11c3babe298e92052564da84"
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/EcYZGTDScR1D7NMc_K1RIRo-Bl8>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Nov 2015 22:19:42 -0000

On Wed, Nov 25, 2015 at 3:58 PM, John Bradley <ve7jtb@ve7jtb.com> 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 <jricher@mit.edu> 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 <
> kathleen.moriarty.ietf@gmail.com> wrote:
>
> Hi,
>
> Sent from my iPhone
>
> On Nov 25, 2015, at 3:20 PM, John Bradley <ve7jtb@ve7jtb.com> 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 <phil.hunt@oracle.com> 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 <jricher@mit.edu> 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 <phil.hunt@oracle.com> 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
> phil.hunt@oracle.com
>
> On Nov 25, 2015, at 10:48 AM, Brian Campbell <bcampbell@pingidentity.com>
> 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 <jricher@mit.edu> 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 <phil.hunt@oracle.com> 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
>> phil.hunt@oracle.com
>>
>> On Nov 25, 2015, at 9:33 AM, Justin Richer <jricher@mit.edu> 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 <bcampbell@pingidentity.com>
>> wrote:
>>
>> Where does it say that?
>>
>>
>>
>> On Wed, Nov 25, 2015 at 8:44 AM, Phil Hunt <phil.hunt@oracle.com> 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 <bcampbell@pingidentity.com>
>>> 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 <phil.hunt@oracle.com> 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
>>>> phil.hunt@oracle.com
>>>>
>>>> > On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org 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
>>>> > OAuth@ietf.org
>>>> > https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>>
>>>
>>> --
>>> [image: Ping Identity logo] <https://www.pingidentity.com/>
>>> Brian Campbell
>>> Distinguished Engineer
>>> Ping Identity
>>> @ bcampbell@pingidentity.com [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
>> @ bcampbell@pingidentity.com [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
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>
>>
>
>
> --
> [image: Ping Identity logo] <https://www.pingidentity.com/>
> Brian Campbell
> Distinguished Engineer
> Ping Identity
> @ bcampbell@pingidentity.com [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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>


-- 

Best regards,
Kathleen