Re: [OAUTH-WG] MTLS token endoint & discovery

[George Fletcher <[e-mail]>]

Unfortunately, even the concept of "signed_metadata" in RFC 8414 isn't 
very specific and allows for arbitrary claims to be signed forcing a 
client to merge values giving the signed claims precedence in the merged 
output (if the client supports signed_metadata).

I agree with your concerns about arbitrarily specifying some endpoints 
as MTLS only and others as not.

It just seems cleaner to say "this is the metadata for the AS with MTLS 
required" and "this is the metadata for the AS without MTLS required". 
The mixing seems like its almost assured to be implemented incorrectly.

Thanks,
George

On 2/12/19 3:36 PM, Justin Richer wrote:
> The problem with this idea is that there’s not a single canonical 
> place for OAuth2 stuff under .well-known, according to the discovery 
> document. OIDC has one, UMA2 has one, and I’m sure there are other 
> flavors as well. It would not make sense for there to be a new one 
> just for MTLS-enabling all of these OAuth-powered protocols.
>
> — Justin
>
>> On Feb 12, 2019, at 3:27 PM, George Fletcher 
>> <gffletch=[e-mail] 
>> <mailto:gffletch=[e-mail]>> wrote:
>>
>> I prefer this approach to an embedded JSON object. Possibly even just 
>> making the MTLS version its own directly referencable config under 
>> .well-known.
>>
>> Thanks,
>> George
>>
>> On 2/12/19 2:47 PM, Richard Backman, Annabelle 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<[e-mail]>on behalf of Brian 
>>> Campbell<bcampbell=[e-mail]>
>>> *Date:*Tuesday, February 12, 2019 at 10:58 AM
>>> *To:*Dominick Baier<[e-mail]>
>>> *Cc:*oauth<[e-mail]>
>>> *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 
>>> <[e-mail] <mailto:[e-mail]>> wrote:
>>>
>>>     IMHO that’s a reasonable and pragmatic option.
>>>     Thanks
>>>     ———
>>>     Dominick
>>>
>>>     On 11. February 2019 at 13:26:37, Brian Campbell
>>>     ([e-mail] <mailto:[e-mail]>)
>>>     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
>>>             <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
>>>             <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
>>>         <[e-mail]
>>>         <mailto:[e-mail]>> 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=[e-mail]
>>>             <mailto:bcampbell=[e-mail]>) 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 <[e-mail]
>>>                 <mailto:[e-mail]>> 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
>>>                     <[e-mail]
>>>                     <mailto:[e-mail]>>
>>>                     *Date:*Wednesday, February 6, 2019 at 11:30 AM
>>>                     *To:*"Richard Backman, Annabelle"
>>>                     <richanna=[e-mail]
>>>                     <mailto:[e-mail]>>
>>>                     *Cc:*"Richard Backman, Annabelle"
>>>                     <[e-mail]
>>>                     <mailto:[e-mail]>>, oauth
>>>                     <[e-mail] <mailto:[e-mail]>>
>>>                     *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
>>>                     <[e-mail]
>>>                     <mailto:[e-mail]>> wrote:
>>>
>>>                         "far" should have said "fair" in the
>>>                         previous message
>>>                         On Tue, Feb 5, 2019 at 4:35 PM Brian
>>>                         Campbell <[e-mail]
>>>                         <mailto:[e-mail]>> 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=[e-mail]
>>>                             <mailto:[e-mail]...org>>
>>>                             wrote:
>>>
>>>                                 (TL;DR: punt AS metadata to a
>>>                                 separate draft)
>>>
>>>                                 AS points #1-3 are all questions I
>>>                                 would have as an implementer:
>>>
>>>                                  1. Section 2 of RFC8414
>>>                                     <https://tools.ietf.org/html/rfc8414#section-2>says
>>>                                     token_endpoint “is REQUIRED
>>>                                     unless only the implicit grant
>>>                                     type is supported.” So what does
>>>                                     the mTLS-only AS put here?
>>>                                  2. The claims for these other
>>>                                     endpoints are OPTIONAL,
>>>                                     potentially leading to
>>>                                     inconsistency depending on how
>>>                                     #1 gets decided.
>>>                                  3. 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.
>>>                                  4. 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 <[e-mail]
>>>                                 <mailto:[e-mail]>> on
>>>                                 behalf of Brian Campbell
>>>                                 <bcampbell=[e-mail]
>>>                                 <mailto:[e-mail]>>
>>>                                 *Date:*Monday, February 4, 2019 at
>>>                                 5:28 AM
>>>                                 *To:*"Richard Backman, Annabelle"
>>>                                 <richanna=[e-mail]
>>>                                 <mailto:[e-mail]>>
>>>                                 *Cc:*oauth <[e-mail]
>>>                                 <mailto:[e-mail]>>
>>>                                 *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=[e-mail]
>>>                                 <mailto:[e-mail]...org>>
>>>                                 wrote:
>>>
>>>                                     Confusion from the AS’s perspective:
>>>
>>>                                      1. 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?
>>>                                      2. What if I only support mTLS
>>>                                         for the token endpoint, but
>>>                                         not revocation or user info?
>>>                                      3. 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?
>>>                                      4. 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:
>>>
>>>                                      1. 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.
>>>                                      2. My AS metadata parser
>>>                                         crashed because the
>>>                                         mTLS-only AS omitted
>>>                                         token_endpoint_uri.
>>>                                      3. My AS metadata parser
>>>                                         crashed because it didn’t
>>>                                         expect to encounter a JSON
>>>                                         object as a parameter value.
>>>                                      4. The mTLS-only AS didn’t
>>>                                         provide a value for
>>>                                         mtls_endpoints, what do I do?
>>>                                      5. 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=[e-mail]
>>>                                     <mailto:[e-mail]>>
>>>                                     *Date:*Friday, February 1, 2019
>>>                                     at 3:17 PM
>>>                                     *To:*"Richard Backman,
>>>                                     Annabelle" <[e-mail]
>>>                                     <mailto:[e-mail]>>
>>>                                     *Cc:*George Fletcher
>>>                                     <[e-mail]
>>>                                     <mailto:[e-mail]>>,
>>>                                     oauth <[e-mail]
>>>                                     <mailto:[e-mail]>>
>>>                                     *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=[e-mail]
>>>                                     <mailto:[e-mail]...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
>>>                                         <[e-mail]
>>>                                         <mailto:[e-mail]>>
>>>                                         on behalf of Brian Campbell
>>>                                         <bcampbell=[e-mail]
>>>                                         <mailto:[e-mail]>>
>>>                                         *Date:*Friday, February 1,
>>>                                         2019 at 1:31 PM
>>>                                         *To:*George Fletcher
>>>                                         <gffletch=[e-mail]
>>>                                         <mailto:40aol.com@dmarc......ietf.org>>
>>>                                         *Cc:*oauth <[e-mail]
>>>                                         <mailto:[e-mail]>>
>>>                                         *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=[e-mail]
>>>                                         <mailto:[e-mail]>>
>>>                                         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
>>>                                                 <[e-mail]
>>>                                                 <mailto:[e-mail]>>
>>>                                                 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
>>>
>>>                                                 [e-mail]  <mailto:[e-mail]>
>>>
>>>                                                 https://www.ietf..org/mailman/listinfo/oauth  <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
>>>                 [e-mail] <mailto:[e-mail]>
>>>                 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/oauth
>