Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: [UNVERIFIED SENDER] Re: New Version Notification for draft-fett-oauth-dpop-03.txt
Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> Thu, 05 December 2019 11:38 UTC
Return-Path: <rifaat.ietf@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFCCE120105 for <oauth@ietfa.amsl.com>; Thu, 5 Dec 2019 03:38:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 5pKb1DsvPI2a for <oauth@ietfa.amsl.com>; Thu, 5 Dec 2019 03:38:21 -0800 (PST)
Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 968DC12004A for <oauth@ietf.org>; Thu, 5 Dec 2019 03:38:21 -0800 (PST)
Received: by mail-il1-x12e.google.com with SMTP id u16so2674264ilg.10 for <oauth@ietf.org>; Thu, 05 Dec 2019 03:38:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lz8OnM39yZRuMBh7l/z7QFbFeiE203wlmhJrDT/na1w=; b=TB8SbBhtsN+dr+7SmKdVG1IwAPfQYuxBzQmChtaHmDEWx06NTglq/8E2feQyJNeF9x VVH93iaqq84Q1zClzONA43Nc1IcdRGmE0altbIw3uSCzRaVGdpBFjBdhP6FLVLi8f8/d BD/xf/sRvjmpJM55m2pygD1l4DuWooZSYxunl+K2t5SSM1Y4bPt7bT7jl7wGybTBtSCA H14z7mNiWtGn58dTIkoPkCsJFN4iKdFivKTxuV3eI0i0BnN66m1YU6UCvutexTIJJ0kd SIzXCNUsMa8nQa7mRtsyTW5zO+PZrplLBk2ia5+SdVvkQ3gA6fYeg2tmIruaeKXBv0gz DWww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lz8OnM39yZRuMBh7l/z7QFbFeiE203wlmhJrDT/na1w=; b=gjV5uuDIQ+8hRe1Q7iOjmpZX3Qrr6e8vwQVT+Wwr83AA9Aa/xf9FWJOc05BuKcjYb2 MOg/oX03NER+Kgno88uWrM1s8908n6uxdnkhWWifmDhJHKRSZPt1RlYn6URuHpYugb6v bphwrJNFyp6O9eHPH0jt1YEMvDNDdWt+4eOFk0Ubdld1JHZ3yRe3Pr5URYrkjogqL+CM b+bRsXKPh62+ygJCWW7NYX2FCJthm1vKc0mhKrlRnXPbg4jNQRJZyvOSRkfn/die+Ij1 /a4HOnqGcHlL/QinujALY64IxCpiOOUzc0/l4og1XJSfg0eEaYKgMvZRegZ15jwYmdA+ Mntg==
X-Gm-Message-State: APjAAAVXvC0+EEDzuR6RGKxUtzIIPQpgls09y0KoL/+QUPJms7+2sZfN +c3AlCURxhBH0tMmsyizDgysc3roMxGEquKC1mA=
X-Google-Smtp-Source: APXvYqyb+gKRWuPjF/e90bedE4osM5ZOVf68VRLC0ZwLdJMi6G5B6Z1ZkGFIWYk0/4c6HgyGpyZQ4uHfBjs8/D0jTiE=
X-Received: by 2002:a92:3984:: with SMTP id h4mr7855644ilf.36.1575545900718; Thu, 05 Dec 2019 03:38:20 -0800 (PST)
MIME-Version: 1.0
References: <6DD96E5F-2F26-4280-BDF9-41F43CB5A3AF@lodderstedt.net> <3F3A350A-0EF3-4968-968E-9325F8434E80@amazon.com> <CAGL6epKY7CX=7x7Dx=qfDjCzZ70+d6hcver6bFagF2RjUR-iCg@mail.gmail.com> <6C747BDA-478A-4E5F-9438-8D766520DB27@amazon.com>
In-Reply-To: <6C747BDA-478A-4E5F-9438-8D766520DB27@amazon.com>
From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Date: Thu, 05 Dec 2019 06:38:08 -0500
Message-ID: <CAGL6epLFyDVQza=0ujq6Qto8-OffGuAbtUgJPuc1hwQa0AVYLw@mail.gmail.com>
To: "Richard Backman, Annabelle" <richanna@amazon.com>
Cc: Torsten Lodderstedt <torsten@lodderstedt.net>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bd60df0598f35dba"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/7wxjxA33lcNLlq9O50mNLSdvVjs>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: [UNVERIFIED SENDER] Re: New Version Notification for draft-fett-oauth-dpop-03.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 05 Dec 2019 11:38:26 -0000
I see what you meant. Thanks, Rifaat On Tue, Dec 3, 2019 at 3:46 PM Richard Backman, Annabelle < richanna@amazon.com> wrote: > >> The documentation for Symantec's SSL Visibility product [1] indicates > that sessions using client certificates will be rejected unless they are > exempted based on destination whitelisting (which is problematic when the > destination may be a general-purpose cloud service provider). > > > > > Is there a use case that would require you to do that? > > > If I have a service that is hosted on AWS, then the exception would be > for my service, not for AWS in general. > > > > Yes. Consider an on-premise service that uses a vendor service hosted in > the cloud. While some SaaS API endpoints are tenant-specific, many (most?) > are not, meaning from a destination perspective the enterprise’s legitimate > traffic looks just like questionable traffic. > > > > – > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> > *Date: *Tuesday, December 3, 2019 at 5:21 AM > *To: *"Richard Backman, Annabelle" <richanna@amazon.com> > *Cc: *Torsten Lodderstedt <torsten@lodderstedt.net>, oauth <oauth@ietf.org > > > *Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: New > Version Notification for draft-fett-oauth-dpop-03.txt > > > > > > > > On Mon, Dec 2, 2019 at 4:35 PM Richard Backman, Annabelle <richanna= > 40amazon.com@dmarc.ietf.org> wrote: > > > Session cookies serve the same purpose in web apps as access tokens for > APIs but there are much more web apps than APIs. I use the analogy to > illustrate that either there are security issues with cloud deployments of > web apps or the techniques used to secure web apps are ok for APIs as well. > > "Security issues" is a loaded term, but if you mean that there are > practical risks that are not addressed by bearer tokens (whether they be > session cookies or access tokens) then yes, I think we both agree that > there are. Otherwise we wouldn't be discussing PoP, sender-constrained > tokens, etc. TLS-based solutions mitigate some risks, while leaving others > unmitigated. Depending on your use case and threat model, these risks may > or may not present practical threats. For my use cases, they do. > > Ultimately I'd like to mitigate these risks for both service APIs and web > applications. My focus is on service APIs for a couple reasons: > > 1. Interoperability is more important when the sender and recipient aren't > necessarily owned by a single entity. I can do proprietary things in > JavaScript if I want to just as I can in client SDKs, but this breaks down > if my API implements a standard protocol and is expected to work with > off-the-shelf clients and/or implementations from other vendors. > > 2. Web applications are just a special subset of service APIs that happens > to be accessed via a browser. A solution for service APIs ought to be > reusable for web applications, or at least serve as a foundation for their > solution. > > > - Have you seen this kind of proxies intercepting the connection from > on-prem service deployments to service provider? I’m asking because I > thought the main use case was to intercept employees PC internet traffic. > > I'm working from second-hand knowledge here, but like most things in the > enterprise world, it depends. Separating employee device outbound traffic > from internal service outbound traffic requires some level of > sophistication, be it in network topology, routing rules, or configuration > rules on the TLIS appliance. > > > > Yeah, many major enterprises have these kinds of inspection services, Take > a look at the following example: > > https://www.zscaler.com/resources/data-sheets/zscaler-internet-access.pdf > > > > > > > - Are you saying this kind of proxy does not support mutual TLS at > all? > > >From what I understand, at the very least mTLS is not universally > supported.. There may be some vendors that support it, but it's not > guaranteed. The documentation for Symantec's SSL Visibility product [1] > indicates that sessions using client certificates will be rejected unless > they are exempted based on destination whitelisting > > > > Yes, that is my experience too. > > > > (which is problematic when the destination may be a general-purpose cloud > service provider). > > > > Is there a use case that would require you to do that? > > If I have a service that is hosted on AWS, then the exception would be for > my service, not for AWS in general. > > > > Regards, > > Rifaat > > > > > > On the other hand, I would expect these kind of proxy to understand a > lot about the protocols running through it, otherwise they cannot fulfil > their task of inspecting this traffic. > > Maybe, maybe not. In any case there's a difference between understanding > HTTP or SMTP or P2P-protocol-du-jour and understanding the > application-level protocol running on top of HTTP. There hasn't been any > need for these proxies to understand OAuth 2.0 thus far. > > [1]: > https://origin-symwisedownload.symantec.com/resources/webguides/sslv/45/Content/Topics/troubleshooting/Support_for_Client_Cert.htm > – > Annabelle Richard Backman > AWS Identity > > > On 12/1/19, 7:41 AM, "Torsten Lodderstedt" <torsten= > 40lodderstedt.net@dmarc.ietf.org> wrote: > > > Annabelle, > > > Am 27.11.2019 um 02:46 schrieb Richard Backman, Annabelle < > richanna@amazon.com>: > > > > Torsten, > > > > I'm not tracking how cookies are relevant to the discussion. > > I’m still trying to understand why you and others argue mTLS cannot be > used in public cloud deployments (and thus focus on application level PoP). > > Session cookies serve the same purpose in web apps as access tokens > for APIs but there are much more web apps than APIs. I use the analogy to > illustrate that either there are security issues with cloud deployments of > web apps or the techniques used to secure web apps are ok for APIs as well. > > Here are the two main arguments and my conclusions/questions: > > 1) mTLS it’s not end 2 end: although that’s true from a connection > perspective, there are solutions employed to secure the last hop(s) between > TLS terminating proxy and service (private net, VPN, TLS). That works and > is considered secure enough for (session) cookies, it should be the same > for access tokens. > > 2) TLS terminating proxies do not forward cert data: if the service > itself terminates TLS this is feasible, we do it for our > public-cloud-hosted mTLS-protected APIs. If TLS termination is provided by > a component run by the cloud provider, the question is: is this component > able to forward the client certificate to the service? If not, web apps > using certs for authentication cannot be supported straightway by the cloud > provider. Any insights? > > > I'm guessing that's because we're not on the same page regarding use > cases, so allow me to clearly state mine: > > I think we are, we are just focusing on different ends of the TLS > tunnel. My focus is on the service provider’s side, esp. public cloud > hosting, whereas you are focusing on client side TLS terminating proxies. > > > > > The use case I am concerned with is requests between services where > end-to-end TLS cannot be guaranteed. For example, an enterprise service > running on-premise, communicating with a service in the cloud, where the > enterprise's outbound traffic is routed through a TLS Inspection (TLSI) > appliance. The TLSI appliance sits in the middle of the communication, > terminating the TLS session established by the on-premise service and > establishing a separate TLS connection with the cloud service. > > > > In this kind of environment, there is no end-to-end TLS connection > between on-premise service and cloud service, and it is very unlikely that > the TLSI appliance is configurable enough to support TLS-based > sender-constraint mechanisms without significantly compromising on the > scope of "sender" (e.g., "this service at this enterprise" becomes "this > enterprise”). > > I’m not familiar with these kind of proxies, but happy to learn more > and to discuss potential solutions. > > Here are some questions: > - Have you seen this kind of proxies intercepting the connection from > on-prem service deployments to service provider? I’m asking because I > thought the main use case was to intercept employees PC internet traffic. > - Are you saying this kind of proxy does not support mutual TLS at > all? At least theoretically, the proxy could combine source and destination > to select a cert/key pair to use for outbound TLS client authentication. > > > Even if it is possible, it is likely to require advanced > configuration that is non-trivial for administrators to deploy. It's no > longer as simple as the developer passing a self-signed certificate to the > HTTP stack. > > I agree. Cert binding is established in OAuth protocol messages, which > would require the appliance to understand the protocol. On the other hand, > I would expect these kind of proxy to understand a lot about the protocols > running through it, otherwise they cannot fulfil their task of inspecting > this traffic. > > best regards, > Torsten. > > > > > > > – > > Annabelle Richard Backman > > AWS Identity > > > > > > On 11/23/19, 9:50 AM, "Torsten Lodderstedt" <torsten@lodderstedt.net> > wrote: > > > > > > > >>>>>>>>> On 23. Nov 2019, at 00:34, Richard Backman, Annabelle < > richanna@amazon.com> wrote: > >>>>>>>>> how are cookies protected from leakage, replay, injection in > a setup like this? > >> They aren’t. > > > > Thats very interesting when compared to what we are discussing with > respect to API security. > > > > It effectively means anyone able to capture a session cookie, e.g. > between TLS termination point and application, by way of an HTML injection, > or any other suitable attack is able to impersonate a legitimate user by > injecting the cookie(s) in an arbitrary user agent. The impact of such an > attack might be even worse than abusing an access token given the > (typically) broad scope of a session. > > > > TLS-based methods for sender constrained access tokens, in contrast, > prevent this type of replay, even if the requests are protected between > client and TLS terminating proxy, only. Ensuring the authenticity of the > client certificate when forwarded from TLS terminating proxy to service, > e.g. through another authenticated TLS connection, will even prevent > injection within the data center/cloud environment. > > > > I come to the conclusion that we already have the mechanism at hand > to implement APIs with a considerable higher security level than what is > accepted today for web applications. So what problem do we want to solve? > > > >> But my primary concern here isn't web browser traffic, it's calls > from services/apps running inside a corporate network to services outside a > corporate network (e.g., service-to-service API calls that pass through a > corporate TLS gateway). > > > > Can you please describe the challenges arising in these settings? I > assume those proxies won’t support CONNECT style pass through otherwise we > wouldn’t talk about them. > > > >>> That’s a totally valid point. But again, such a solution makes the > life of client developers harder. > >>> I personally think, we as a community need to understand the pros > and cons of both approaches. I also think we have not even come close to > this point, which, in my option, is the prerequisite for making informed > decisions. > >> Agreed. It's clear that there are a number of parties coming at > this from a number of different directions, and that's coloring our > perceptions. That's why I think we need to nail down the scope of what > we're trying to solve with DPoP before we can have a productive > conversation how it should work. > > > > We will do so. > > > >> – > >> Annabelle Richard Backman > >> AWS Identity > >> On 11/22/19, 10:51 PM, "Torsten Lodderstedt" < > torsten@lodderstedt.net> wrote: > >>>> On 22. Nov 2019, at 22:12, Richard Backman, Annabelle <richanna= > 40amazon.com@dmarc.ietf.org> wrote: > >>> The service provider doesn't own the entire connection. They have > no control over corporate or government TLS gateways, or other terminators > that might exist on the client's side. In larger organizations, or when > cloud hosting is involved, the service team may not even own all the hops > on their side. > >> how are cookies protected from leakage, replay, injection in a > setup like this? > >>> While presumably they have some trust in them, protection against > leaked bearer tokens is an attractive defense-in-depth measure. > >> That’s a totally valid point. But again, such a solution makes the > life of client developers harder. > >> I personally think, we as a community need to understand the pros > and cons of both approaches. I also think we have not even come close to > this point, which, in my option, is the prerequisite for making informed > decisions. > >>> – > >>> Annabelle Richard Backman > >>> AWS Identity > >>> On 11/22/19, 9:37 PM, "OAuth on behalf of Torsten Lodderstedt" < > oauth-bounces@ietf.org on behalf of torsten= > 40lodderstedt.net@dmarc.ietf.org> wrote: > >>>> On 22. Nov 2019, at 21:21, Richard Backman, Annabelle <richanna= > 40amazon.com@dmarc.ietf.org> wrote: > >>>> The dichotomy of "TLS working" and "TLS failed" only applies to a > single TLS connection. In non-end-to-end TLS environments, each TLS > terminator between client and RS introduces additional token > leakage/exfiltration risk, irrespective of the quality of the TLS > connections themselves. Each terminator also introduces complexity for > implementing mTLS, Token Binding, or any other TLS-based sender constraint > solution, which means developers with non-end-to-end TLS use cases will be > more likely to turn to DPoP. > >>> The point is we are talking about different developers here. The > client developer does not need to care about the connection between proxy > and service. She relies on the service provider to get it right. So the > developers (or DevOps or admins) of the service provider need to ensure end > to end security. And if the path is secured once, it will work for all > clients. > >>>> If DPoP is intended to address "cases where neither mTLS nor > OAuth Token Binding are available" [1], then it should address this risk of > token leakage between client and RS. If on the other hand DPoP is only > intended to support the SPA use case and assumes the use of end-to-end TLS, > then the document should be updated to reflect that. > >>> I agree. > >>>> [1]: > https://tools.ietf.org/html/draft-fett-oauth-dpop-03#section-1 > >>>> – > >>>> Annabelle Richard Backman > >>>> AWS Identity > >>>> On 11/22/19, 8:17 PM, "OAuth on behalf of Torsten Lodderstedt" < > oauth-bounces@ietf.org on behalf of torsten= > 40lodderstedt.net@dmarc.ietf.org> wrote: > >>>> Hi Neil, > >>>>> On 22. Nov 2019, at 18:08, Neil Madden < > neil.madden@forgerock.com> wrote: > >>>>> On 22 Nov 2019, at 07:53, Torsten Lodderstedt <torsten= > 40lodderstedt.net@dmarc.ietf.org> wrote: > >>>>>>> On 22. Nov 2019, at 15:24, Justin Richer <jricher@mit.edu> > wrote: > >>>>>>> I’m going to +1 Dick and Annabelle’s question about the scope > here. That was the one major thing that struck me during the DPoP > discussions in Singapore yesterday: we don’t seem to agree on what DPoP is > for. Some (including the authors, it seems) see it as a quick > point-solution to a specific use case. Others see it as a general PoP > mechanism. > >>>>>>> If it’s the former, then it should be explicitly tied to one > specific set of things. If it’s the latter, then it needs to be expanded. > >>>>>> as a co-author of the DPoP draft I state again what I said > yesterday: DPoP is a mechanism for sender-constraining access tokens sent > from SPAs only. The threat to be prevented is token replay. > >>>>> I think the phrase "token replay" is ambiguous. Traditionally it > refers to an attacker being able to capture a token (or whole requests) in > use and then replay it against the same RS. This is already protected > against by the use of normal TLS on the connection between the client and > the RS. I think instead you are referring to a malicious/compromised RS > replaying the token to a different RS - which has more of the flavour of a > man in the middle attack (of the phishing kind). > >>>> I would argue TLS basically prevents leakage and not replay. The > threats we try to cope with can be found in the Security BCP. There are > multiple ways access tokens can leak, including referrer headers, mix-up, > open redirection, browser history, and all sorts of access token leakage at > the resource server > >>>> Please have a look at > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4. > >>>> > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4.8 > also has an extensive discussion of potential counter measures, including > audience restricted access tokens and a conclusion to recommend sender > constrained access tokens over other mechanisms. > >>>>> But if that's the case then there are much simpler defences than > those proposed in the current draft: > >>>>> 1. Get separate access tokens for each RS with correct audience > and scopes. The consensus appears to be that this is hard to do in some > cases, hence the draft. > >>>> How many deployments do you know that today are able to issue > RS-specific access tokens? > >>>> BTW: how would you identify the RS? > >>>> I agree that would be an alternative and I’m a great fan of such > tokens (and used them a lot at Deutsche Telekom) but in my perception this > pattern needs still to be established in the market. Moreover, they > basically protect from a rough RS (if the URL is used as audience) > replaying the token someplace else, but they do not protect from all other > kinds of leakage/replay (e.g. log files). > >>>>> 2. Make the DPoP token be a simple JWT with an "iat" and the > origin of the RS. This stops the token being reused elsewhere but the > client can reuse it (replay it) for many requests.. > >>>>> 3. Issue a macaroon-based access token and the client can add a > correct audience and scope restrictions at the point of use. > >>>> Why is this needed if the access token is already audience > restricted? Or do you propose this as alternative? > >>>>> Protecting against the first kind of replay attacks only becomes > an issue if we assume the protections in TLS have failed. But if DPoP is > only intended for cases where mTLS can't be used, it shouldn't have to > protect against a stronger threat model in which we assume that TLS > security has been lost. > >>>> I agree. > >>>> best regards, > >>>> Torsten. > >>>>> -- Neil > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > >
- Re: [OAUTH-WG] New Version Notification for draft… Neil Madden
- [OAUTH-WG] Fwd: New Version Notification for draf… Brian Campbell
- Re: [OAUTH-WG] Fwd: New Version Notification for … Denis
- Re: [OAUTH-WG] New Version Notification for draft… Neil Madden
- Re: [OAUTH-WG] New Version Notification for draft… Paul Querna
- Re: [OAUTH-WG] New Version Notification for draft… Neil Madden
- Re: [OAUTH-WG] New Version Notification for draft… David Waite
- Re: [OAUTH-WG] New Version Notification for draft… Torsten Lodderstedt
- Re: [OAUTH-WG] New Version Notification for draft… Brian Campbell
- Re: [OAUTH-WG] New Version Notification for draft… Neil Madden
- Re: [OAUTH-WG] New Version Notification for draft… Brian Campbell
- Re: [OAUTH-WG] New Version Notification for draft… Neil Madden
- Re: [OAUTH-WG] New Version Notification for draft… Richard Backman, Annabelle
- Re: [OAUTH-WG] New Version Notification for draft… Neil Madden
- Re: [OAUTH-WG] New Version Notification for draft… Dick Hardt
- Re: [OAUTH-WG] New Version Notification for draft… Justin Richer
- Re: [OAUTH-WG] New Version Notification for draft… Rob Otto
- Re: [OAUTH-WG] New Version Notification for draft… Torsten Lodderstedt
- Re: [OAUTH-WG] New Version Notification for draft… Torsten Lodderstedt
- Re: [OAUTH-WG] New Version Notification for draft… Mike Jones
- Re: [OAUTH-WG] New Version Notification for draft… Filip Skokan
- Re: [OAUTH-WG] New Version Notification for draft… Torsten Lodderstedt
- Re: [OAUTH-WG] New Version Notification for draft… Rob Otto
- Re: [OAUTH-WG] New Version Notification for draft… Filip Skokan
- Re: [OAUTH-WG] New Version Notification for draft… Torsten Lodderstedt
- Re: [OAUTH-WG] New Version Notification for draft… Mike Jones
- Re: [OAUTH-WG] New Version Notification for draft… Torsten Lodderstedt
- Re: [OAUTH-WG] New Version Notification for draft… Dick Hardt
- Re: [OAUTH-WG] New Version Notification for draft… Neil Madden
- Re: [OAUTH-WG] New Version Notification for draft… Neil Madden
- Re: [OAUTH-WG] New Version Notification for draft… Aaron Parecki
- Re: [OAUTH-WG] New Version Notification for draft… Neil Madden
- Re: [OAUTH-WG] New Version Notification for draft… Petteri Stenius
- Re: [OAUTH-WG] New Version Notification for draft… Torsten Lodderstedt
- Re: [OAUTH-WG] New Version Notification for draft… Torsten Lodderstedt
- Re: [OAUTH-WG] New Version Notification for draft… Richard Backman, Annabelle
- Re: [OAUTH-WG] New Version Notification for draft… Jim Manico
- Re: [OAUTH-WG] New Version Notification for draft… Neil Madden
- Re: [OAUTH-WG] New Version Notification for draft… Richard Backman, Annabelle
- Re: [OAUTH-WG] New Version Notification for draft… Torsten Lodderstedt
- Re: [OAUTH-WG] New Version Notification for draft… Torsten Lodderstedt
- Re: [OAUTH-WG] New Version Notification for draft… Richard Backman, Annabelle
- Re: [OAUTH-WG] New Version Notification for draft… Torsten Lodderstedt
- Re: [OAUTH-WG] New Version Notification for draft… Richard Backman, Annabelle
- Re: [OAUTH-WG] New Version Notification for draft… Torsten Lodderstedt
- Re: [OAUTH-WG] New Version Notification for draft… Neil Madden
- Re: [OAUTH-WG] New Version Notification for draft… Neil Madden
- Re: [OAUTH-WG] New Version Notification for draft… Torsten Lodderstedt
- Re: [OAUTH-WG] New Version Notification for draft… Dave Tonge
- Re: [OAUTH-WG] New Version Notification for draft… Neil Madden
- Re: [OAUTH-WG] New Version Notification for draft… Torsten Lodderstedt
- Re: [OAUTH-WG] New Version Notification for draft… Neil Madden
- Re: [OAUTH-WG] New Version Notification for draft… Jared Jennings
- Re: [OAUTH-WG] New Version Notification for draft… Aaron Parecki
- Re: [OAUTH-WG] New Version Notification for draft… Torsten Lodderstedt
- Re: [OAUTH-WG] New Version Notification for draft… Richard Backman, Annabelle
- Re: [OAUTH-WG] New Version Notification for draft… Neil Madden
- Re: [OAUTH-WG] New Version Notification for draft… Richard Backman, Annabelle
- Re: [OAUTH-WG] New Version Notification for draft… Richard Backman, Annabelle
- Re: [OAUTH-WG] New Version Notification for draft… Neil Madden
- Re: [OAUTH-WG] New Version Notification for draft… Brian Campbell
- Re: [OAUTH-WG] New Version Notification for draft… Brian Campbell
- Re: [OAUTH-WG] New Version Notification for draft… Richard Backman, Annabelle
- Re: [OAUTH-WG] New Version Notification for draft… Neil Madden
- Re: [OAUTH-WG] New Version Notification for draft… Neil Madden
- Re: [OAUTH-WG] New Version Notification for draft… Richard Backman, Annabelle
- Re: [OAUTH-WG] New Version Notification for draft… Richard Backman, Annabelle
- Re: [OAUTH-WG] New Version Notification for draft… Neil Madden
- Re: [OAUTH-WG] New Version Notification for draft… Torsten Lodderstedt
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: New Versio… Richard Backman, Annabelle
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: New Versio… Rifaat Shekh-Yusef
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: [UNVERIFIE… Richard Backman, Annabelle
- Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: [UNVERIFIE… Rifaat Shekh-Yusef