Re: [OAUTH-WG] Cache-Control headers for Bearer URI Query Parameter method
On 19/06/2012 12:54 p.m., Mike Jones wrote: Could the experts on this thread please summarize the outcome of this thread? Was the conclusion that no changes were required to either Core or Bearer? Or if you believe that changes are required to one or both drafts, could you please propose exact wording changes for review by the working group? IMHO they are correct as-is. No changes need be made to either. AYJ Thanks, -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt Sent: Monday, June 11, 2012 11:07 PM To: Phil Hunt Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Cache-Control headers for Bearer URI Query Parameter method thanks a lot Am 12.06.2012 01:03, schrieb Phil Hunt: Thanks. That makes sense. Phil On 2012-06-11, at 15:39, Amos Jeffries wrote: On 12.06.2012 07:23, Phil Hunt wrote: Private also seems inappropriate since no operation should be cached for oauth as even when the same requestor. Phil There is a difference in HTTP use-case between what the Bearer and core specs are covering. The core spec appears to be covering the request/response messages transferring credentials in the response entity. These mandate "no-store", which adds strict erasure requirements for any middleware and browser caches handling the response. Even single-user caches like a browser are not allowed to store the HTTP copy of the credentials response. Bearer is requiring "private" only in the specific HTTP case where the token is in query params and response is some data object (ie images or HTML page). Such that trusted proxies and other third-parties who do not implement OAuth but do relay HTTP treat the request and reply securely. With uses of Bearer via HTTP authentication framework this "private" is implicit. In these cases the response MAY be cached by a private browser cache, but not by third-party proxies. no-store is overkill and wastes bandwidth in this case. I hope this clarifies. AYJ On 2012-06-11, at 12:17, Torsten Lodderstedt wrote: Hi all, I noticed a difference in usage of cache control headers between bearer and core spec. core -27 states: " The authorization server MUST include the HTTP "Cache-Control" response header field [RFC2616] with a value of "no-store" in any response containing tokens, credentials, or other sensitive information, as well as the "Pragma" response header field [RFC2616] with a value of "no-cache"." So a "Pragma" response header field is required instead of the "Cache-Control" header "private". Not instead of. *As well as*. Pragma "no-cache" only tells the third-party to revalidate before using the response, it does not prevent storage and thus potential data leakage. As far as I understand, both specs are nearly but not fully equivalent. Do we need to align both? regards, Torsten. Am 09.06.2012 00:20, schrieb Mike Jones: Hi Amos, The OAuth Bearer specification now includes the Cache-Control language we’d discussed. See the fifth paragraph of http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-20#section-2.3. Thanks again, -- Mike From: oauth-boun...@ietf.org On Behalf Of Mike Jones Sent: Thursday, May 17, 2012 3:12 PM Subject: [OAUTH-WG] Cache-Control headers for Bearer URI Query Parameter method Dear working group members: I'm going through the remaining open issues that have been raised about the Bearer spec so as to be ready to publish an updated draft once the outstanding consensus call issues are resolved. Amos Jeffries had cited this requirement in the HTTPbis spec ( http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-19#section-2.3.1): o The credentials carried in an Authorization header field are specific to the User Agent, and therefore have the same effect on HTTP caches as the "private" Cache-Control response directive, within the scope of the request they appear in. Therefore, new authentication schemes which choose not to carry credentials in the Authorization header (e.g., using a newly defined header) will need to explicitly disallow caching, by mandating the use of either Cache-Control request directives (e.g., "no-store") or response directives (e.g., "private"). I propose to add the following text in order to satisfy this requirement. I have changed Amos' MUSTs to SHOULDs because, in practice, applications that have no option but to use the URI Query Parameter method are likely to also not have control over the request's Cache-Control directives (just as they do not have the
Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions
On 14.06.2012 06:40, John Bradley wrote: That would probably work as well. That is why I am not particularly concerned about excluding the : We originally used the URI itself, mostly for convenience of debugging, but there are other potential options. The authorization server needs to compare the client_id and the redirect uri. But it could compare the hash with not much more work. Also a sha256 hash is probably longer than the uri it is hashing. I am not super concerned with being able to have : in the client_id John B. If I'm following all these threads correctly the only explicit problem with URI in client_id is HTTP username field being : terminated. As such it does not have to be a hash per-se, just an encoding that removes ":" and other reserved characters from the on-wire form *when sent via HTTP*. AYJ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Cache-Control headers for Bearer URI Query Parameter method
On 12.06.2012 07:23, Phil Hunt wrote: Private also seems inappropriate since no operation should be cached for oauth as even when the same requestor. Phil There is a difference in HTTP use-case between what the Bearer and core specs are covering. The core spec appears to be covering the request/response messages transferring credentials in the response entity. These mandate "no-store", which adds strict erasure requirements for any middleware and browser caches handling the response. Even single-user caches like a browser are not allowed to store the HTTP copy of the credentials response. Bearer is requiring "private" only in the specific HTTP case where the token is in query params and response is some data object (ie images or HTML page). Such that trusted proxies and other third-parties who do not implement OAuth but do relay HTTP treat the request and reply securely. With uses of Bearer via HTTP authentication framework this "private" is implicit. In these cases the response MAY be cached by a private browser cache, but not by third-party proxies. no-store is overkill and wastes bandwidth in this case. I hope this clarifies. AYJ On 2012-06-11, at 12:17, Torsten Lodderstedt wrote: Hi all, I noticed a difference in usage of cache control headers between bearer and core spec. core -27 states: " The authorization server MUST include the HTTP "Cache-Control" response header field [RFC2616] with a value of "no-store" in any response containing tokens, credentials, or other sensitive information, as well as the "Pragma" response header field [RFC2616] with a value of "no-cache"." So a "Pragma" response header field is required instead of the "Cache-Control" header "private". Not instead of. *As well as*. Pragma "no-cache" only tells the third-party to revalidate before using the response, it does not prevent storage and thus potential data leakage. As far as I understand, both specs are nearly but not fully equivalent. Do we need to align both? regards, Torsten. Am 09.06.2012 00:20, schrieb Mike Jones: Hi Amos, The OAuth Bearer specification now includes the Cache-Control language we’d discussed. See the fifth paragraph of http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-20#section-2.3. Thanks again, -- Mike From: oauth-boun...@ietf.org On Behalf Of Mike Jones Sent: Thursday, May 17, 2012 3:12 PM Subject: [OAUTH-WG] Cache-Control headers for Bearer URI Query Parameter method Dear working group members: I'm going through the remaining open issues that have been raised about the Bearer spec so as to be ready to publish an updated draft once the outstanding consensus call issues are resolved. Amos Jeffries had cited this requirement in the HTTPbis spec ( http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-19#section-2.3.1): o The credentials carried in an Authorization header field are specific to the User Agent, and therefore have the same effect on HTTP caches as the "private" Cache-Control response directive, within the scope of the request they appear in. Therefore, new authentication schemes which choose not to carry credentials in the Authorization header (e.g., using a newly defined header) will need to explicitly disallow caching, by mandating the use of either Cache-Control request directives (e.g., "no-store") or response directives (e.g., "private"). I propose to add the following text in order to satisfy this requirement. I have changed Amos' MUSTs to SHOULDs because, in practice, applications that have no option but to use the URI Query Parameter method are likely to also not have control over the request's Cache-Control directives (just as they do not have the ability to use an "Authorization: Bearer" header value): Clients using the URI Query Parameter method SHOULD also send a Cache-Control header containing the "no-store" option. Server success (2XX status) responses to these requests SHOULD contain a Cache-Control header with the "private" option. Comments? -- Mike -Original Message- From: Amos Jeffries On 24/04/2012 4:33 p.m., Mike Jones wrote: > What specific language would you suggest be added to what section(s)? > > -- Mike Perhapse the last paragraph appended: " Because of the security weaknesses associated with the URI method (see Section 5), including the high likelihood that the URL containing the access token w
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-19.txt
On 24/04/2012 4:33 p.m., Mike Jones wrote: What specific language would you suggest be added to what section(s)? -- Mike Perhapse the last paragraph appended: " Because of the security weaknesses associated with the URI method (see Section 5), including the high likelihood that the URL containing the access token will be logged, it SHOULD NOT be used unless it is impossible to transport the access token in the "Authorization" request header field or the HTTP request entity-body. Resource servers compliant with this specification MAY support this method. Clients requesting URL containing the access token MUST also send a Cache-Control header containing the "no-store" option. Server success (2xx status) responses to these requests MUST contain a Cache-Control header with the "private" option. " I'm a little suspicious that the "SHOUDL NOT" in that top paragraph likely should be a MUST NOT to further discourage needless use. AYJ -Original Message- From: oauth-boun...@ietf.org On Behalf Of Amos Jeffries Sent: Monday, April 23, 2012 7:10 PM To: oauth@ietf.org Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-19.txt On 24.04.2012 13:46, internet-dra...@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 : The OAuth 2.0 Authorization Protocol: Bearer Tokens Author(s) : Michael B. Jones Dick Hardt David Recordon Filename: draft-ietf-oauth-v2-bearer-19.txt Pages : 24 Date: 2012-04-23 This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-19.txt The section 2.3 (URL Query Parameter) text is still lacking explicit and specific security requirements. The overarching TLS requirement is good in general, but insufficient in the presence of HTTP intermediaries on the TLS connection path as is becoming a common practice. The upcoming HTTPbis specs document this issue as a requirement for new auth schemes such as Bearer: http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-19#section-2.3.1 " Therefore, new authentication schemes which choose not to carry credentials in the Authorization header (e.g., using a newly defined header) will need to explicitly disallow caching, by mandating the use of either Cache-Control request directives (e.g., "no-store") or response directives (e.g., "private"). " AYJ ___ 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
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-19.txt
On 24.04.2012 13:46, internet-dra...@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 : The OAuth 2.0 Authorization Protocol: Bearer Tokens Author(s) : Michael B. Jones Dick Hardt David Recordon Filename: draft-ietf-oauth-v2-bearer-19.txt Pages : 24 Date: 2012-04-23 This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-19.txt The section 2.3 (URL Query Parameter) text is still lacking explicit and specific security requirements. The overarching TLS requirement is good in general, but insufficient in the presence of HTTP intermediaries on the TLS connection path as is becoming a common practice. The upcoming HTTPbis specs document this issue as a requirement for new auth schemes such as Bearer: http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-19#section-2.3.1 " Therefore, new authentication schemes which choose not to carry credentials in the Authorization header (e.g., using a newly defined header) will need to explicitly disallow caching, by mandating the use of either Cache-Control request directives (e.g., "no-store") or response directives (e.g., "private"). " AYJ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth Bearer authentication - for proxies?
On 4/01/2012 3:58 p.m., Igor Faynberg wrote: Very good to have a clear sequence! Many thanks for all the work explaining this to me. Maybe my misunderstanding can be corrected by considering observations 1) and 2) and answering question 3) in-line: On 1/3/2012 8:30 PM, Amos Jeffries wrote: ... Here is a transaction sequence for that bank: client 1 to proxy: GET /?oauth_token=FOO HTTP/1.1 Host: bank.example.com 1): If this transaction is done over TLS, then this specific proxy is the ONLY entity in the chain that knows the token at the moment, and since it is in the same domain as the server, we must assume its fidelity.. The client does too, surely. Fidelity, well; * it is going to cache the reply for re-use, <=== this is what I worry about. * it is going to log the URL+token for a longish term, * it may pass the URL+token in unencrypted packets (via ICP, HTCP, UDP syslog) to any peers it may have, Given these risks are all internal to the security domain and so very slight, they are still weak points in the transactions long-term integrity. Adding the cache-controls erases the risks related to caching. With correct CC headers URL replay would fail even if TLS were not present. proxy to server: GET /?oauth_token=FOO HTTP/1.1 Host: bank.example.com 2) Now the server knows it, too. (server verifies the token "FOO" is valid for client 1 through the proxy) bank server to proxy: HTTP/1.1 200 OK stuff proxy to client 1: HTTP/1.1 200 OK stuff .. some time passes. The token "FOO" expires, gets replaced by token "FOO-2". client 1 to proxy: GET /?oauth_token=FOO-2 HTTP/1.1 Host: bank.example.com Same as in 1) proxy to server: GET /?oauth_token=FOO-2 HTTP/1.1 Host: bank.example.com Sane as in 2) (server verifies the token "FOO-2" is valid for client 1 through the proxy) bank server to proxy: HTTP/1.1 200 OK other-stuff proxy to client 1: HTTP/1.1 200 OK other-stuff Attacker processes some URL records they somehow swiped from the client transactions... 3) How can attacker swipe it, if the token was passed *as part of an encrypted payload?* In the last year or so it has become safe to assume SSL/TLS is compromised by MITM. Or alternatively some secondary infection at one of the end points. Paranoia dictates that someone will figure it out somehow if the stakes are high enough. When they do, its a good idea to have the rest of the system firmly sealed. The given sequence was for the reverse-proxy. The alternative scenario is an identical sequence with a SSL interception proxy. For example an installation of: http://wiki.squid-cache.org/Features/SslBump. In that alternative the proxy is outside the servers security domain and inside some third-party ISP domain at the user end. AYJ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth Bearer authentication - for proxies?
On Tue, 03 Jan 2012 18:34:01 -0500, Igor Faynberg wrote: Well, this exchange made me read all I could find on reverse proxies. Now I understand--and agree with--the last statement of AYJ: '"the server" is a proxy. ' But my understanding is that the proxy (which DNS pointed me to when I tried to get to my bank) belongs in the domain "mybank," and this proxy had been issued a valid certificate--which I had ascertained in the process of authentication. So, the end result is that the proxy is part of the bank. If we expect it to be harmful to the bank--so we could the "server" itself as well as any bank's employee. It would be the bank replaying things to itself, right? I'm not sure we quite match ideas on this. The problem is between the client and proxy. Not between the proxy and the server. Here is a transaction sequence for that bank: client 1 to proxy: GET /?oauth_token=FOO HTTP/1.1 Host: bank.example.com proxy to server: GET /?oauth_token=FOO HTTP/1.1 Host: bank.example.com (server verifies the token "FOO" is valid for client 1 through the proxy) bank server to proxy: HTTP/1.1 200 OK stuff proxy to client 1: HTTP/1.1 200 OK stuff .. some time passes. The token "FOO" expires, gets replaced by token "FOO-2". client 1 to proxy: GET /?oauth_token=FOO-2 HTTP/1.1 Host: bank.example.com proxy to server: GET /?oauth_token=FOO-2 HTTP/1.1 Host: bank.example.com (server verifies the token "FOO-2" is valid for client 1 through the proxy) bank server to proxy: HTTP/1.1 200 OK other-stuff proxy to client 1: HTTP/1.1 200 OK other-stuff Attacker processes some URL records they somehow swiped from the client transactions... attacker to proxy: GET /?oauth_token=FOO HTTP/1.1 Host: bank.example.com proxy to attacker: HTTP/1.1 200 OK stuff ... Oops. attacker to proxy: GET /?oauth_token=FOO-2 HTTP/1.1 Host: bank.example.com proxy to attacker: HTTP/1.1 200 OK other-stuff ... Oops. I assume for clarity that the server and client 1 have both correctly implemented Bearer and are performing proper validation and expiry on the query-string tokens. The mitigation is for the server which implements Bearer to be sending Cache-Control with one of the values: no-store, private, proxy-revalidate and/or must-revalidate. AYJ Then it is the bank's problem, not OAuth's as far as I am concerned... Igor On 1/2/2012 7:36 PM, Amos Jeffries wrote: On 1/2/2012 7:07 AM, Amos Jeffries wrote: On 2/01/2012 11:00 p.m., Torsten Lodderstedt wrote: ... general note: I do not understand why caching proxies should impose a problem in case TLS is used (end2end). Could you please explain? Because TLS is hop-by-hop (in HTTP hops, end-to-end only in TCP hops). Proxies which decrypt TLS and provide responses out of cache are already deployed in many places. Mostly in the form of reverse-proxies, but corporate decryption proxies are also on the increase. AYJ On 3/01/2012 11:17 a.m., Igor Faynberg wrote: I am at a loss here; granted, it is a gray area... Does it mean that RFC 2817 has not been implemented properly? From RFC 2817: " 5. Upgrade across Proxies As a hop-by-hop header, Upgrade is negotiated between each pair of HTTP counterparties. If a User Agent sends a request with an Upgrade header to a proxy, it is requesting a change to the protocol between itself and the proxy, not an end-to-end change. " The more common case is CONNECT method from RFC 2068, from a user agent to a reverse-proxy. Same behaviour. To make it simple: At the client, I establish a session key with the server, and then use it for confidentiality. How is this key known to any proxy? "the server" is a proxy. AYJ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth Bearer authentication - for proxies?
On 1/2/2012 7:07 AM, Amos Jeffries wrote: On 2/01/2012 11:00 p.m., Torsten Lodderstedt wrote: ... general note: I do not understand why caching proxies should impose a problem in case TLS is used (end2end). Could you please explain? Because TLS is hop-by-hop (in HTTP hops, end-to-end only in TCP hops). Proxies which decrypt TLS and provide responses out of cache are already deployed in many places. Mostly in the form of reverse-proxies, but corporate decryption proxies are also on the increase. AYJ On 3/01/2012 11:17 a.m., Igor Faynberg wrote: I am at a loss here; granted, it is a gray area... Does it mean that RFC 2817 has not been implemented properly? From RFC 2817: " 5. Upgrade across Proxies As a hop-by-hop header, Upgrade is negotiated between each pair of HTTP counterparties. If a User Agent sends a request with an Upgrade header to a proxy, it is requesting a change to the protocol between itself and the proxy, not an end-to-end change. " The more common case is CONNECT method from RFC 2068, from a user agent to a reverse-proxy. Same behaviour. To make it simple: At the client, I establish a session key with the server, and then use it for confidentiality. How is this key known to any proxy? "the server" is a proxy. AYJ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth Bearer authentication - for proxies?
On 2/01/2012 11:00 p.m., Torsten Lodderstedt wrote: Hi, Amos, I believe that the draft addresses the replay matters by specifying the validity time field. Do you see a problem with that? I did not see any such validity time field in the HTTP mechanisms. You mean the validity period of the token itself? that would be irrelevant as the case I am raising is for software which does not support Bearer specs. Even if the software is not aware of the bearer spec, a token that becomes invalid after a certain time span cannot sucessfully be replayed any longer. There is no time span limit mentioned in the section 2.3 when token is passed in the query string. That is my point. Proxies which cache and obey HTTP but not Bearer *will* answer to replay attacks by providing the supposedly secure response body. general note: I do not understand why caching proxies should impose a problem in case TLS is used (end2end). Could you please explain? Because TLS is hop-by-hop (in HTTP hops, end-to-end only in TCP hops). Proxies which decrypt TLS and provide responses out of cache are already deployed in many places. Mostly in the form of reverse-proxies, but corporate decryption proxies are also on the increase. AYJ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth Bearer authentication - for proxies?
On 2/01/2012 7:25 p.m., Igor Faynberg wrote: On 12/30/2011 10:14 PM, Amos Jeffries wrote: Reading section 2.3, it appears this method of transferring the credentials is open to replay attacks when caching TLS middleware is present. I believe this spec should mandate cache controls on responses using that method. Otherwise a lot of HTTP compliant middleware will feel free to store and supply the protected response to later replay attacks. Amos, I believe that the draft addresses the replay matters by specifying the validity time field. Do you see a problem with that? I did not see any such validity time field in the HTTP mechanisms. You mean the validity period of the token itself? that would be irrelevant as the case I am raising is for software which does not support Bearer specs. (1) assuming the client is malicious and cannot be trusted to follow the bearer token limits. (2) the proxy acting as server for the transaction does *not* support bearer and is thus not implementing any bearer token time limitations. The HTTP definition of www-auth specifies an implicit "Cache-Control: private" unless explicit "public" is added. The cache supports the HTTP imiplicit definitinon and does not cache the reply. Replay requests will get nothing from the cache. In the query string case proxies use the full abolute URL (including query string with token) as part of the storage key. The HTTP spec outlines that the absence of cache-control time limitations permits a proxy to store the reply as long as it wishes. Meaning that any time limits imposed by the Bearer spec around the token itself are not supported. Therefore Therefore any client requesting the URL with the token can be presented with a cached reply *indefinitely*. At no point between malicious client and proxy is any bearer implementation involved. (I did not understand what "HTTP-compliant middleware" meant, but if it is something at the proxies, I think this is further addressed by making TLS a must--which will make the token simply invisible.) By "HTTP compolliant middleware" I mean any software which obeys HTTP proxy guidelines but not necessarily OAuth or other specifications. There are alot of those. With best wishes for the New Year to you and all OAuthers, Igor Igor ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth Bearer authentication - for proxies?
re-posting for cc to OAuth WG On 25/12/2011 7:21 p.m., Amos Jeffries wrote: On Sat, 24 Dec 2011 08:46:45 -0500, Mark Nottingham wrote: The OAUTH WG is creating a new authentication scheme for bearer tokens: http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-15 Reading section 2.3, it appears this method of transferring the credentials is open to replay attacks when caching TLS middleware is present. I believe this spec should mandate cache controls on responses using that method. Otherwise a lot of HTTP compliant middleware will feel free to store and supply the protected response to later replay attacks. During review, I wondered whether this might be a suitable scheme for proxies; the draft doesn't currently specify it as such, and our list of considerations for new schemes asks them to consider this. Do any of the proxy implementers on the list have thoughts about this / possible interest in it? I think it would be a good idea to prepare for. Quite a few admin these days consider transit to be a service that needs authenticating as much as any origin server resource. It might even encourage progress on the TLS proxy connection developments we have been waiting for. AYJ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
