I feel I have to disagree. I agree that optionality is often complexity and
should be avoided. But, I think the optionality here is an agility feature
allowing mtls to work across a diversified market of different types of tls
terminators with varying capability. Lack of appropriate discovery/options
could serve to make the spec unusable in many cases.
A complicating factor with tls is that a tls layer failure prevents the AS from
issuing a correcting directive like an http error or http redirect.
We have to be sure not to break existing clients so we may in some cases need
mtls only endpoints. I am not far enough along to know for sure. But I tend to
agree with Brian on this.
This may be a sign we need more implementation data (including from tls wg) to
make the right call.
Phil
> On Feb 14, 2019, at 8:56 AM, Dominick Baier <dba...@leastprivilege.com> wrote:
>
> Sorry - this was not meant to be snide at all.
>
> It was honest feedback that you also need to keep software complexity in mind
> when creating a spec. Every MAY or OPTIONAL, or do it like this OR that, or
> send values in arbitrary order adds to complexity. Complexity is the natural
> enemy of security.
>
> Cheers
> ———
> Dominick
>
>> On 13. February 2019 at 20:39:16, Richard Backman, Annabelle
>> (richa...@amazon.com) wrote:
>>
>> The issue is that the proposal violates the standard by changing the
>> semantics of a parameter it defines. We should be very, very, VERY careful
>> about telling implementers to violate an existing standard.. This change
>> might prove incompatible with existing or future implementations of 8414, it
>> might not, but by violating the standard the proposal creates an opportunity
>> for incompatibility that didn’t exist before.
>>
>>
>>
>> As far as simplicity is concerned, I find a solution that reuses the
>> existing data model and naturally supports existing and future extensions to
>> be far simpler than one that introduces ambiguous semantics to existing
>> parameters. Generally speaking, data models with properties that mean
>> different things in different contexts tend to be fragile and require more
>> complex code to work with. But that’s just my experience as, you know, an
>> actual developer.
>>
>>
>>
>> Let’s keep the assumptions and snide remarks about others’ backgrounds off
>> the list, please.
>>
>>
>>
>> --
>>
>> Annabelle Richard Backman
>>
>> AWS Identity
>>
>>
>>
>>
>>
>> From: Dominick Baier <dba...@leastprivilege.com>
>> Date: Wednesday, February 13, 2019 at 4:18 AM
>> To: "Richard Backman, Annabelle" <richa...@amazon.com>, Filip Skokan
>> <panva...@gmail.com>
>> Cc: Brian Campbell <bcampb...@pingidentity.com>, "Richard Backman,
>> Annabelle" <richa...@amazon.com>, oauth <oauth@ietf.org>
>> Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS token endoint & discovery
>>
>>
>>
>> I am for keeping it simple and not introducing another link to follow.
>>
>>
>>
>> I sometimes wonder how many of the spec authors are actually developers -
>> these suggestions make software unnecessary complex ;)
>>
>>
>>
>> ———
>>
>> Dominick
>>
>>
>>
>> On 13. February 2019 at 12:25:13, Filip Skokan (panva...@gmail.com) wrote:
>>
>> Hello,
>>
>>
>>
>> Additionally, a metadata document that omits token_endpoint in favor of
>> mtls_endpoints since only mTLS is supported would violate 8414, as 8414 says
>> token_endpoint “is REQUIRED unless only the implicit grant type is
>> supported.”
>>
>>
>> mtls only AS doesn't get anything out of using mtls_endpoints, its use
>> should not be recommended for such AS and regular endpoints will be used,
>> this satisfies the requirement
>>
>> Here is one example, based on my understanding of the “straw man” format
>> presented in this thread: RFC8414 defines the value of
>> token_endpoint_auth_methods_supported as a “JSON array containing a list of
>> client authentication methods supported by this token endpoint.” If that
>> array contains “tls_client_auth” and the endpoint specified in
>> token_endpoint does not support mTLS, then that metadata violates 8414. You
>> could address this by adding a token_endpoint_auth_methods_supported
>> parameter to the mtls_endpoints object, and likewise for the other endpoints
>> and auth methods. If you take that to its logical conclusion, you end up
>> with a complete metadata document hanging off of mtls_endpoints. It’s that
>> line of thought that led me to suggest just pointing to an alternate
>> document.
>>
>>
>> Assuming we go with using the same root auth methods property, what's the
>> issue? Clients not having mtls capabilities won't care about the additional
>> method members being present. Clients that do implement mtls by the
>> specification will know to look for mtls_endpoints and fall back to regular
>> ones if the specific endpoint or mtls_endpoints root property is not present.
>>
>>
>>
>> I gave `mtls_alternate_metadata` route a thought and don't see how it helps,
>> given the two above are non-issues (my $.02) another discovery document only
>> brings more of them since every property can now be different, not just the
>> endpoints.
>>
>>
>>
>> S pozdravem,
>> Filip Skokan
>>
>>
>>
>>
>>
>> On Wed, 13 Feb 2019 at 00:00, Richard Backman, Annabelle
>> <richa...@amazon..com> wrote:
>>
>> Here is one example, based on my understanding of the “straw man” format
>> presented in this thread: RFC8414 defines the value of
>> token_endpoint_auth_methods_supported as a “JSON array containing a list of
>> client authentication methods supported by this token endpoint.” If that
>> array contains “tls_client_auth” and the endpoint specified in
>> token_endpoint does not support mTLS, then that metadata violates 8414. You
>> could address this by adding a token_endpoint_auth_methods_supported
>> parameter to the mtls_endpoints object, and likewise for the other endpoints
>> and auth methods. If you take that to its logical conclusion, you end up
>> with a complete metadata document hanging off of mtls_endpoints. It’s that
>> line of thought that led me to suggest just pointing to an alternate
>> document.
>>
>>
>>
>> Additionally, a metadata document that omits token_endpoint in favor of
>> mtls_endpoints since only mTLS is supported would violate 8414, as 8414 says
>> token_endpoint “is REQUIRED unless only the implicit grant type is
>> supported.”
>>
>>
>>
>> It is possible to define the mtls_endpoints parameter such that the above
>> use cases are invalid, but that does make the document more complicated. If
>> we go the “mtls_alternate_metadata” route, we can skip past all of these
>> issues, because it brings us back to just parsing the same metadata that we
>> do today.
>>
>>
>>
>> --
>>
>> Annabelle Richard Backman
>>
>> AWS Identity
>>
>>
>>
>>
>>
>> From: OAuth <oauth-boun...@ietf.org> on behalf of Filip Skokan
>> <panva...@gmail.com>
>> Date: Tuesday, February 12, 2019 at 1:13 PM
>> To: "Richard Backman, Annabelle" <richanna=40amazon....@dmarc.ietf.org>
>> Cc: Brian Campbell <bcampbell=40pingidentity....@dmarc.ietf.org>, oauth
>> <oauth@ietf.org>
>> Subject: Re: [OAUTH-WG] MTLS token endoint & discovery
>>
>>
>>
>> Hi Annabelle,
>>
>>
>>
>> can you elaborate what would be the violation / negative impact of usage of
>> RFC8414?
>>
>>
>>
>> As it already makes use of `signed_metadata` and this language is present ...
>>
>>
>>
>> > Consumers of the metadata MAY ignore the signed metadata if they do not
>> > support this feature. If the consumer of the metadata supports signed
>> > metadata, metadata values conveyed in the signed metadata MUST take
>> > precedence over the corresponding values conveyed using plain JSON
>> > elements.
>>
>>
>>
>> ... would mtls_endpoints be any different? Clients are free to ignore this
>> if they don't support/use mtls, and if they do those values must take
>> precedence over the root ones. the use of mtls_endpoints would not be
>> recommended for mtls-only AS but recommended for one with both mtls/regular
>> authentication methods. token_endpoint remains required for all intents and
>> purposes. And as for the usable client authentication methods - they should
>> all be listed, or do you think we should separate the ones for each
>> hostname/port location? To what end? Is there a risk having the mtls
>> hostname/port accepting regular requests? Other then secret/key _jwt auth
>> methods assertion aud claim the endpoint location doesn't play a role in the
>> authentication process.
>>
>>
>>
>> Best,
>> Filip
>>
>>
>>
>>
>>
>> On Tue, 12 Feb 2019 at 20:47, Richard Backman, Annabelle
>> <richanna=40amazon....@dmarc.ietf.org> wrote:
>>
>> I’m not opposed to introducing a metadata change, if the scenario is
>> relevant and other approaches can’t adequately address it – and I’ll readily
>> grant that we probably don’t want to depend on consistency of browser
>> behavior at the intersection of client certificates and
>> Access-Control-Allow-Credentials. But care needs to be taken in designing
>> that metadata to avoid violating or otherwise negatively impacting usage of
>> RFC8414.
>>
>>
>>
>> Along those lines, instead of adding an “mtls_endpoints” metadata parameter,
>> we could add an “mtls_alternate_metadata” parameter whose value is the URL
>> of an alternate metadata document intended for clients using mTLS. An
>> mTLS-optional AS could have two different metadata documents for mTLS and
>> non-mTLS clients, reducing the mTLS-optional scenario to the mTLS-only
>> scenario. This sidesteps the challenges of aligning the “either/or”
>> semantics of mTLS-optional with some of the rigid parameter definitions in
>> RFC8414 (see: token_endpoint, token_endpoint_auth_methods_supported).
>>
>>
>>
>> --
>>
>> Annabelle Richard Backman
>>
>> AWS Identity
>>
>>
>>
>>
>>
>> From: OAuth <oauth-boun...@ietf.org> on behalf of Brian Campbell
>> <bcampbell=40pingidentity....@dmarc.ietf.org>
>> Date: Tuesday, February 12, 2019 at 10:58 AM
>> To: Dominick Baier <dba...@leastprivilege.com>
>> Cc: oauth <oauth@ietf.org>
>> Subject: Re: [OAUTH-WG] MTLS token endoint & discovery
>>
>>
>>
>> Thanks for the input, Dominick.
>>
>>
>>
>> I'd said previously that I was having trouble adequately gauging whether or
>> not there's sufficient consensus to go ahead with the update. I was even
>> thinking of asking the chairs about a consensus call during the office hours
>> meeting yesterday. But it got canceled. And looking again back over the
>> discussion, I don't believe a consensus call is necessary. There's been a
>> lot of general discussion over the last several weeks during which several
>> folks have stated support for the proposal while there's been only one voice
>> of direct dissent. That seems like rough enough consensus and, as such, I
>> plan to make the change in the next revision of the document (which should
>> be done soon). Chairs, please let me know, if you believe the situation
>> warrants a different course of action.
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Feb 11, 2019 at 11:01 PM Dominick Baier <dba...@leastprivilege.com>
>> wrote:
>>
>> IMHO that’s a reasonable and pragmatic option.
>>
>>
>>
>> Thanks
>>
>> ———
>>
>> Dominick
>>
>>
>>
>> On 11. February 2019 at 13:26:37, Brian Campbell
>> (bcampb...@pingidentity.com) wrote:
>>
>> It's been pointed out that the potential issue is not isolated to the just
>> token endpoint but that revocation, introspection, etc. could be impacted as
>> well. So, at this point, the proposal on the table is to add a new optional
>> AS metadata parameter named 'mtls_endpoints' that's value we be a JSON
>> object which itself contains endpoints that, when present, a client doing
>> MTLS would use rather than the regular endpoints. A straw-man example might
>> look like this
>>
>> {
>> "issuer":"https://server.example.com";,
>> "authorization_endpoint":"https://server.example.com/authz";,
>> "token_endpoint":"https://server.example.com/token";,
>> "token_endpoint_auth_methods_supported":[
>> "client_secret_basic","tls_client_auth", "none"],
>> "userinfo_endpoint":"https://server.example.com/userinfo";,
>> "revocation_endpoint":"https://server.example.com/revo";,
>> "jwks_uri":"https://server.example.com/jwks.json";,
>> "mtls_endpoints":{
>> "token_endpoint":"https://mtls.example.com/token";,
>> "userinfo_endpoint":"https://mtls.example.com/userinfo";,
>> "revocation_endpoint":"https://mtls.example.com/revo";
>> }
>> }
>>
>>
>>
>> A client doing MTLS would look for and give precedence to an endpoint under
>> "mtls_endpoints" while falling back to use the normal endpoint from the top
>> level of metadata when/if its not in "mtls_endpoints".
>>
>>
>> The idea being that "regular" clients (those not doing MTLS) will use the
>> regular endpoints. And only the host/port of the endpoints listed in
>> mtls_endpoints will be set up to request TLS client certificates during
>> handshake. Thus any potential impact of the CertificateRequest message being
>> sent in the TLS handshake can be avoided for all the other regular clients
>> that are not going to do MTLS - including and most importantly in-browser
>> javascript clients where there can be less than desirable UI presented to
>> the end-user.
>>
>>
>>
>> I'm struggling, however, to adequately gauge whether or not there's
>> sufficient consensus to go ahead with the update. There's been some support
>> for it voiced. As well as talk of other approaches that could be
>> alternatives or additional measures. And also some vocal opposition to it.
>>
>>
>>
>>
>>
>> On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier <dba...@leastprivilege.com>
>> wrote:
>>
>> We are currently implementing MTLS in IdentityServer.
>>
>>
>>
>> Our approach will be that we’ll offer a separate token endpoint that
>> supports client certs. Are you planning on adding an official endpoint name
>> for discovery? Right now we are using “mtls_token_endpoint”.
>>
>>
>>
>> Thanks
>>
>> ———
>>
>> Dominick
>>
>>
>>
>> On 7. February 2019 at 22:36:55, Brian Campbell
>> (bcampbell=40pingidentity....@dmarc.ietf.org) wrote:
>>
>> Ah yes, that makes sense. Thanks for clarifying. And it is indeed a good
>> reminder that even a seemingly innocuous change that should be backwards
>> compatible can break things unexpectedly..
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Annabelle
>> <richa...@amazon.com> wrote:
>>
>> The case I’m referencing didn’t specifically involve AS metadata. We had
>> clients in the wild that assumed that all the properties in the JSON object
>> returned from our userinfo endpoint were scalar strings. This broke when we
>> introduced a new property whose value was a JSON object. It was a good
>> reminder that even a seemingly innocuous change that should be backwards
>> compatible can force more work on clients than we expect.
>>
>>
>>
>> --
>>
>> Annabelle Richard Backman
>>
>> AWS Identity
>>
>>
>>
>>
>>
>> From: Brian Campbell <bcampb...@pingidentity..com>
>> Date: Wednesday, February 6, 2019 at 11:30 AM
>> To: "Richard Backman, Annabelle" <richanna=40amazon....@dmarc.ietf.org>
>> Cc: "Richard Backman, Annabelle" <richa...@amazon.com>, oauth
>> <oa...@ietf..org>
>> Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients
>> using the token endpoint
>>
>>
>>
>> And I'm honestly really struggling to see what could have gone wrong with or
>> how token_endpoint_auth_methods broke something with the user info endpoint.
>> If you have the time and/or it'd be informative to this here little
>> discussion, please explain that one a bit more.
>>
>>
>>
>> On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell <bcampb...@pingidentity.com>
>> wrote:
>>
>> "far" should have said "fair" in the previous message
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell <bcampb...@pingidentity.com>
>> wrote:
>>
>> It may well be due to my own intellectual shortcomings but these
>> issues/questions/confusion-points are not resonating for me as being
>> problematic.
>>
>>
>>
>> The more general stance of "this isn't needed or worth it in this document"
>> (I think that's far?) is being heard though.
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle
>> <richanna=40amazon....@dmarc.ietf.org> wrote:
>>
>> (TL;DR: punt AS metadata to a separate draft)
>>
>> AS points #1-3 are all questions I would have as an implementer:
>>
>> Section 2 of RFC8414 says token_endpoint “is REQUIRED unless only the
>> implicit grant type is supported.” So what does the mTLS-only AS put here?
>> The claims for these other endpoints are OPTIONAL, potentially leading to
>> inconsistency depending on how #1 gets decided.
>> The example usage of the token_endpoint_auth_methods property given earlier
>> is incompatible with RFC8414, since some of its contents are only valid for
>> the non-mTLS endpoints, and others are only valid for the mTLS endpoints.
>> Hence this question.
>> This introduces a new metadata property that could impact how other specs
>> should extend AS metadata. That needs to be addressed.
>>
>>
>> I could go on for client points but you already get the point. Though I’ll
>> share that #3 is real and once forced me to roll back an update to the Login
>> with Amazon userinfo endpoint…good times. 😃
>>
>>
>>
>> I don’t necessarily think an AS metadata property is wrong per se, but
>> understand that you’re bolting a layer of flexibility onto a standard that
>> wasn’t designed for that, and I don’t think the metadata proposal as it’s
>> been discussed here sufficiently deals with the fallout from that. In my
>> view this is a complex enough issue and it’s for a nuanced enough use case
>> (as far as I can tell from discussion? Please correct me if I’m wrong) that
>> we should punt it to a separate draft (e.g., “Authorization Server Metadata
>> Extensions for mTLS Hybrids”) and get mTLS out the door.
>>
>>
>>
>> --
>>
>> Annabelle Richard Backman
>>
>> AWS Identity
>>
>>
>>
>>
>>
>> From: OAuth <oauth-boun...@ietf.org> on behalf of Brian Campbell
>> <bcampbell=40pingidentity....@dmarc.ietf.org>
>> Date: Monday, February 4, 2019 at 5:28 AM
>> To: "Richard Backman, Annabelle" <richanna=40amazon....@dmarc.ietf.org>
>> Cc: oauth <oauth@ietf.org>
>> Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients
>> using the token endpoint
>>
>>
>>
>> Those points of confusion strike me as somewhat hypothetical or hyperbolic.
>> But your general point is taken and your position of being anti additional
>> metadata on this issue is noted.
>>
>>
>>
>> All of which leaves me a bit uncertain about how to proceed. There seem to
>> be a range of opinions on this point and gauging consensus is proving
>> elusive for me. That's confounded by my own opinion on it being somewhat
>> fluid.
>>
>>
>>
>> And I'd really like to post an update to this draft about a month or two ago.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle
>> <richanna=40amazon....@dmarc.ietf.org> wrote:
>>
>> Confusion from the AS’s perspective:
>>
>> If I only support mTLS, do I need to include both token_endpoint_uri and
>> mtls_endpoints? Should I omit token_endpoint_uri? Or set it to the empty
>> string?
>> What if I only support mTLS for the token endpoint, but not revocation or
>> user info?
>> How do I specify authentication methods for the mTLS token endpoint? Does
>> token_endpoint_auth_methods apply to both the mTLS and non-mTLS endpoints?
>> I’m using the OAuth 2.0 Device Flow. Do I include a mTLS-enabled
>> device_authorization_endpoint under mtls_endpoints?
>>
>>
>> Confusion from the client’s perspective:
>>
>> As far as I know, I’m a public client, and don’t know anything about mTLS,
>> but the IT admins installed client certs in their users’ browsers and the AS
>> expects to use that to authenticate me.
>> My AS metadata parser crashed because the mTLS-only AS omitted
>> token_endpoint_uri.
>> My AS metadata parser crashed because it didn’t expect to encounter a JSON
>> object as a parameter value.
>> The mTLS-only AS didn’t provide a value for mtls_endpoints, what do I do?
>> I don’t know what that “m” means, but they told me to use HTTPS, so I should
>> use the one with “tls” in its name, right?
>>
>>
>> Yes, you can write normative text that answers most of these. But you’ll
>> have to clearly cover a lot of similar-but-slightly-different scenarios and
>> be very explicit. And implementers will still get it wrong. The metadata
>> change introduces opportunities for confusion and failure that do not exist
>> now, and forces them on everyone who supports mTLS. In contrast, the 307
>> redirect is only required when an AS wants to support both, and is
>> unambiguous in its behavior and meaning.
>>
>>
>>
>> --
>>
>> Annabelle Richard Backman
>>
>> AWS Identity
>>
>>
>>
>>
>>
>> From: Brian Campbell <bcampbell=40pingidentity....@dmarc.ietf.org>
>> Date: Friday, February 1, 2019 at 3:17 PM
>> To: "Richard Backman, Annabelle" <richa...@amazon.com>
>> Cc: George Fletcher <gffle...@aol.com>, oauth <oauth@ietf.org>
>> Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser clients
>> using the token endpoint
>>
>>
>>
>> It doesn't seem like that confusing or large of a change to me - if the
>> client is doing MTLS and the given endpoint is present in `mtls_endpoints`,
>> then it uses that one. Otherwise it uses the regular endpoint. It gives an
>> AS a lot of flexibility in deployment options. I personally think getting a
>> 307 approach deployed and working would be more complicated and error prone.
>>
>>
>>
>> It is a minority use case at the moment but there are forces in play, like
>> the push for increased security in general and to have javascript clients
>> use the code flow, that suggest it won't be terribly unusual to see an AS
>> that wants to support MTLS clients and javascript/spa clients at the same
>> time.
>>
>>
>>
>> I've personally wavered back and forth in this thread on whether or not to
>> add the new metadata (or something like it). With my reasoning each way
>> kinda explained somewhere back in the 40 or so messages that make up this
>> thread. But it seems like the rough consensus of the group here is in favor
>> of it.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle
>> <richanna=40amazon....@dmarc.ietf.org> wrote:
>>
>> This strikes me as a very prominent and confusing change to support what
>> seems to be a minority use case. I’m getting a headache just thinking about
>> the text needed to clarify when the AS should provide `mtls_endpoints` and
>> when the client should use that versus using `token_endpoint.` Why is the
>> 307 status code insufficient to cover the case where a single AS supports
>> both mTLS and non-mTLS?
>>
>>
>>
>> --
>>
>> Annabelle Richard Backman
>>
>> AWS Identity
>>
>>
>>
>>
>>
>> From: OAuth <oauth-boun...@ietf.org> on behalf of Brian Campbell
>> <bcampbell=40pingidentity....@dmarc.ietf.org>
>> Date: Friday, February 1, 2019 at 1:31 PM
>> To: George Fletcher <gffletch=40aol....@dmarc.ietf.org>
>> Cc: oauth <oauth@ietf.org>
>> Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint
>>
>>
>>
>> Yes, that would work.
>>
>>
>>
>> On Fri, Feb 1, 2019 at 2:28 PM George Fletcher
>> <gffletch=40aol....@dmarc.ietf.org> wrote:
>>
>> What if the AS wants to ONLY support MTLS connections. Does it not specify
>> the optional "mtls_endpoints" and just use the normal metadata values?
>>
>> On 1/15/19 8:48 AM, Brian Campbell wrote:
>>
>> It would definitely be optional, apologies if that wasn't made clear. It'd
>> be something to the effect of optional for the AS to include and clients
>> doing MTLS would use it when present in AS metadata.
>>
>>
>>
>> On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge <dave.to...@momentumft.co.uk>
>> wrote:
>>
>> I'm in favour of the `mtls_endpoints` metadata parameter - although it
>> should be optional.
>>
>>
>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
>> material for the sole use of the intended recipient(s). Any review, use,
>> distribution or disclosure by others is strictly prohibited.. If you have
>> received this communication in error, please notify the sender immediately
>> by e-mail and delete the message and any file attachments from your
>> computer. Thank you.
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf..org/mailman/listinfo/oauth
>>
>>
>>
>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
>> material for the sole use of the intended recipient(s). Any review, use,
>> distribution or disclosure by others is strictly prohibited.. If you have
>> received this communication in error, please notify the sender immediately
>> by e-mail and delete the message and any file attachments from your
>> computer. Thank you.
>>
>>
>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
>> material for the sole use of the intended recipient(s). Any review, use,
>> distribution or disclosure by others is strictly prohibited.. If you have
>> received this communication in error, please notify the sender immediately
>> by e-mail and delete the message and any file attachments from your
>> computer. Thank you.
>>
>>
>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
>> material for the sole use of the intended recipient(s). Any review, use,
>> distribution or disclosure by others is strictly prohibited.. If you have
>> received this communication in error, please notify the sender immediately
>> by e-mail and delete the message and any file attachments from your
>> computer. Thank you.
>>
>>
>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
>> material for the sole use of the intended recipient(s). Any review, use,
>> distribution or disclosure by others is strictly prohibited. If you have
>> received this communication in error, please notify the sender immediately
>> by e-mail and delete the message and any file attachments from your
>> computer. Thank you.
>>
>>
>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
>> material for the sole use of the intended recipient(s). Any review, use,
>> distribution or disclosure by others is strictly prohibited.. If you have
>> received this communication in error, please notify the sender immediately
>> by e-mail and delete the message and any file attachments from your
>> computer. Thank you. _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
>> material for the sole use of the intended recipient(s). Any review, use,
>> distribution or disclosure by others is strictly prohibited. If you have
>> received this communication in error, please notify the sender immediately
>> by e-mail and delete the message and any file attachments from your
>> computer. Thank you.
>>
>>
>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
>> material for the sole use of the intended recipient(s). Any review, use,
>> distribution or disclosure by others is strictly prohibited.. If you have
>> received this communication in error, please notify the sender immediately
>> by e-mail and delete the message and any file attachments from your
>> computer. Thank you.
>>
>> _______________________________________________
>> 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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
