[OAUTH-WG] FW: OAuth WG Virtual Office Hours

[webex]

BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Romance Standard Time
BEGIN:STANDARD
DTSTART:16010101T03
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN=webex;SENT-BY="MAILTO:hannes.tschofe...@arm.com":MAILTO:messenge
 r...@webex.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=IETF oauth
  WG:MAILTO:oauth@ietf.org
DESCRIPTION;LANGUAGE=en-US:Hi all\,\n\ntoday is the last OAuth WG Virtual O
 ffice Hour.\nThis is a chance to discuss open issues and other administrat
 ive tasks the chairs need to take care of.\n\nCiao\nHannes & Rifaat\n\n---
 --Original Appointment-\nFrom: webex >\nTo: webex\; Web Authorization Protocol Working Group\nSu
 bject: OAuth WG Virtual Office Hours\nWhen: Montag\, 17. Dezember 2018 17:
 30-18:30 Europe Time.\nWhere: https://ietf.webex.com/ietf\n\nJoin WebEx me
 eting\nMeeting number (access code): 319 789 694\n\n\nHost key: 952795\n\n
 \nMeeting password:\n\nn2XuY4zX\n\n\n\n\n\nJoin by phone\n1-650-479-3208 C
 all-in toll number (US/Canada)\n\n\n\nCan't join the meeting? Contact supp
 ort.\n\nIMPORTANT NOTICE: Please note that
  this WebEx service allows audio and other information sent during the ses
 sion to be recorded\, which may be discoverable in a legal matter. You sho
 uld inform all meeting attendees prior to recording if you intend to recor
 d the meeting.\nIMPORTANT NOTICE: The contents of this email and any attac
 hments are confidential and may also be privileged. If you are not the int
 ended recipient\, please notify the sender immediately and do not disclose
  the contents to any other person\, use it for any purpose\, or store or c
 opy the information in any medium. Thank you.\n
UID:cfe18ee1-6e60-46c1-a888-f0111fe15b95
RECURRENCE-ID;TZID=Romance Standard Time:20181217T173000
SUMMARY;LANGUAGE=en-US:FW: OAuth WG Virtual Office Hours
DTSTART;TZID=Romance Standard Time:20181217T173000
DTEND;TZID=Romance Standard Time:20181217T183000
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20180521T153000Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:1526492049
LOCATION;LANGUAGE=en-US:https://ietf.webex.com/ietf
X-MICROSOFT-CDO-APPT-SEQUENCE:1526492049
X-MICROSOFT-CDO-OWNERAPPTID:-1
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:3
X-MICROSOFT-DONOTFORWARDMEETING:FALSE
X-MICROSOFT-DISALLOW-COUNTER:FALSE
X-MICROSOFT-LOCATIONS:[{"DisplayName":"https://ietf.webex.com/ietf"\,"Locat
 ionAnnotation":""\,"LocationUri":""\,"LocationStreet":""\,"LocationCity":"
 "\,"LocationState":""\,"LocationCountry":""\,"LocationPostalCode":""\,"Loc
 ationFullAddress":""}]
BEGIN:VALARM
DESCRIPTION:REMINDER
TRIGGER;RELATED=START:-PT15M
ACTION:DISPLAY
END:VALARM
END:VEVENT
END:VCALENDAR
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] MTLS and in-browser clients using the token endpoint

[Brian Campbell]

While there's been some disagreement about the specific wording etc., there
does seem to be general consensus coming out of this WG to, in one form or
another, recommend against the use of the implicit grant in favor of
authorization code. In order to follow that recommendation, in-browser
JavaScript clients will need to use XHR/fetch (and likely CORS) to make
requests directly to the token endpoint.

Meanwhile there is the MTLS document
 utilizes TLS client
certificates at the token endpoint for client authentication and/or
certificate bound access tokens. The security BCP draft even recommends
sender/key constrained access tokens and MTLS is close to the only viable
way to do that at this time.

Unfortunately, however, these two things don't play very nice together.
When a browser makes a TLS connection where a client cert is requested by
the server in the handshake, even when client certificates are optional and
even when it's fetch/XHR, most/many/all browsers will throw up some kind of
certificate selection interface to the user.  Which is typically a very
very bad user experience. From a practical standpoint, this means that a
single deployment cannot really support the MTLS draft and have in-browser
JavaScript clients using authorization code at the same time.

In order to address the conflict here, I'd propose that the MTLS draft
introduce a new optional AS metadata parameter that is an MTLS enabled
token endpoint alias. Clients that are doing MTLS client authentication
and/or certificate bound access tokens would/should/must use the
alternative token endpoint when present in the AS's metadata. While all
other clients continue to use the standard token endpoint as they always
have. This would allow for an AS to deploy an alternative token endpoint
alias on a distinct host or port where it will request client certs in the
TLS handshake for OAuth clients that use it while keeping the regular token
endpoint as it normally is for other clients, especially in-browser
JavaScript clients.

Thoughts, objections, agreements, etc., on this proposal?

PS Bikeshedding on a name for the metadata parameter is also welcome. Some
ideas to start:
token_endpoint_mtls_alias
token_endpoint_mtls
mtls_token_endpoint_alias
mtls_token_endpoint
alt_token_endpoint_mtls
mtls_token_endpoint_alt
a_token_endpoint_that_a_client_wanting_to_do_mtls_stuff_a_la_RFC_[TBD]_should_use
equally_poor_idea_here

-- 
_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-WG] Conclusion ... OAuth Security Topics -- Recommend authorization code instead of implicit

[Hannes Tschofenig]

Hi all,

Rifaat and I went through the discussion in an effort to judge the outcome.

First, we would like to thank you all for your input. Torsten, as the editor of 
the OAuth Security BCP, got lots of good feedback.

Second, there is strong support recommending against the implicit grant and the 
response types "token id_token" and "code token id_token" for all future 
applications. For already deployed applications please do your threat analysis 
and make your own judgement.

Here is a proposal for the new text in Section 2.1.2 of the Security BCP:
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10



2.1.2.  Implicit Grant

   The implicit grant (response type "token") and other response types
   causing the authorization server to issue access tokens in the
   authorization response are vulnerable to access token leakage and
   access token replay as described in Section 3.1, Section 3.2,
   Section 3.3, and Section 3.6.

   Moreover, no viable mechanism exists to cryptographically bind access
   tokens issued in the authorization response to a certain client as it
   is recommended in Section 2.2.  This makes replay detection for such
   access tokens at resource servers impossible.

   In order to avoid these issues, clients SHOULD NOT use the implicit
   grant (response type "token") or any other response type issuing
   access tokens in the authorization response, such as "token id_token"
   and "code token id_token", unless the issued access tokens are
   sender-constrained and access token injection in the authorization
   response is prevented.

   A sender constrained access token scopes the applicability of an access
   token to a certain sender. This sender is obliged to demonstrate knowledge
   of a certain secret as prerequisite for the acceptance of that token at
   the recipient (e.g., a resource server).

   Clients SHOULD instead use the response type "code" (aka
   authorization code grant type) as specified in Section 2.1.1 or any
   other response type that causes the authorization server to issue
   access tokens in the token response.  This allows the authorization
   server to detect replay attempts and generally reduces the attack
   surface since access tokens are not exposed in URLs.  It also allows
   the authorization server to sender-constrain the issued tokens.


There was a lot of feedback for advice on how to implement OAuth with 
single-page applications. Aaron has been working on a draft and we are planning 
to start a call for adoption. This document will be a natural home for 
describing solutions. Here is the link to the draft: 
https://tools.ietf.org/html/draft-parecki-oauth-browser-based-apps-02

Ciao
Hannes & Rifaat

PS: We would like to remind you about the upcoming OAuth Security Workshop in 
Stuttgart/Germany (March 20-22, 2019) where we will speak about the 
above-mentioned topics and much more. Here is the link:
https://sec.uni-stuttgart.de/events/osw2019

From: Hannes Tschofenig
Sent: Montag, 19. November 2018 11:34
To: oauth 
Subject: OAuth Security Topics -- Recommend authorization code instead of 
implicit


Hi all,



The authors of the OAuth Security Topics draft came to the conclusion that it 
is not possible to adequately secure the implicit flow against token injection 
since potential solutions like token binding or JARM are in an early stage of 
adoption. For this reason, and since CORS allows browser-based apps to send 
requests to the token endpoint, Torsten suggested to use the authorization code 
instead of the implicit grant in call cases in his presentation (see 
https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01).



A hum in the room at IETF#103 concluded strong support for his recommendations. 
We would like to confirm the discussion on the list.



Please provide a response by December 3rd.



Ciao

Hannes & Rifaat

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Call for Adoption: OAuth 2.0 for Browser-Based Apps

[Hannes Tschofenig]

Hi all,

We would like to get a confirmation on the mailing list for the adoption of 
https://tools.ietf.org/html/draft-parecki-oauth-browser-based-apps-02 as a 
starting point for a BCP document about *OAuth 2.0 for Browser-Based Apps*.

Please, let us know if you support or object to the adoption of this document 
by Jan. 7th 2019.

Ciao
Hannes & Rifaat
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[John Bradley]

Yes that is a general problem with browsers and MTLS.

A separate token endpoint is probably useful.

I don't really see SPA doing mutual TLS as likely, however once MTLS is 
turned on on the token endpoint for some clients it can mess up other 
browser and non browser clients.


A separate endpoint in discovery is a good idea  they can always both 
point to the same place.


John B.

On 12/17/2018 12:26 PM, Brian Campbell wrote:
While there's been some disagreement about the specific wording etc., 
there does seem to be general consensus coming out of this WG to, in 
one form or another, recommend against the use of the implicit grant 
in favor of authorization code. In order to follow that 
recommendation, in-browser JavaScript clients will need to use 
XHR/fetch (and likely CORS) to make requests directly to the token 
endpoint.


Meanwhile there is the MTLS document 
 utilizes TLS 
client certificates at the token endpoint for client authentication 
and/or certificate bound access tokens. The security BCP draft even 
recommends sender/key constrained access tokens and MTLS is close to 
the only viable way to do that at this time.


Unfortunately, however, these two things don't play very nice 
together. When a browser makes a TLS connection where a client cert is 
requested by the server in the handshake, even when client 
certificates are optional and even when it's fetch/XHR, most/many/all 
browsers will throw up some kind of certificate selection interface to 
the user.  Which is typically a very very bad user experience. From a 
practical standpoint, this means that a single deployment cannot 
really support the MTLS draft and have in-browser JavaScript clients 
using authorization code at the same time.


In order to address the conflict here, I'd propose that the MTLS draft 
introduce a new optional AS metadata parameter that is an MTLS enabled 
token endpoint alias. Clients that are doing MTLS client 
authentication and/or certificate bound access tokens 
would/should/must use the alternative token endpoint when present in 
the AS's metadata. While all other clients continue to use the 
standard token endpoint as they always have. This would allow for an 
AS to deploy an alternative token endpoint alias on a distinct host or 
port where it will request client certs in the TLS handshake for OAuth 
clients that use it while keeping the regular token endpoint as it 
normally is for other clients, especially in-browser JavaScript clients.


Thoughts, objections, agreements, etc., on this proposal?

PS Bikeshedding on a name for the metadata parameter is also welcome. 
Some ideas to start:

token_endpoint_mtls_alias
token_endpoint_mtls
mtls_token_endpoint_alias
mtls_token_endpoint
alt_token_endpoint_mtls
mtls_token_endpoint_alt
a_token_endpoint_that_a_client_wanting_to_do_mtls_stuff_a_la_RFC_[TBD]_should_use
equally_poor_idea_here







/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

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[Neil Madden]

I am currently running a Tomcat instance that I have configured to support, but 
not demand, client certificates using the 
certificateVerification=“optionalNoCA” setting. With this config I am able to 
authenticate a confidential client using mTLS, and yet connecting to the same 
server over HTTPS in either Safari or Chrome on Mac does not prompt me for any 
certificate. I don’t have any client certificates configured in my browser, so 
does this only happen if you do?

Depending on the deployment scenario, it may also be possible to terminate TLS 
at a proxy and use a separate proxy for (intranet) mTLS clients vs public 
clients, but that may not suit every deployment.

— Neil

> On 17 Dec 2018, at 20:26, Brian Campbell 
>  wrote:
> 
> While there's been some disagreement about the specific wording etc., there 
> does seem to be general consensus coming out of this WG to, in one form or 
> another, recommend against the use of the implicit grant in favor of 
> authorization code. In order to follow that recommendation, in-browser 
> JavaScript clients will need to use XHR/fetch (and likely CORS) to make 
> requests directly to the token endpoint.
> 
> Meanwhile there is the MTLS document utilizes TLS client certificates at the 
> token endpoint for client authentication and/or certificate bound access 
> tokens. The security BCP draft even recommends sender/key constrained access 
> tokens and MTLS is close to the only viable way to do that at this time. 
> 
> Unfortunately, however, these two things don't play very nice together. When 
> a browser makes a TLS connection where a client cert is requested by the 
> server in the handshake, even when client certificates are optional and even 
> when it's fetch/XHR, most/many/all browsers will throw up some kind of 
> certificate selection interface to the user.  Which is typically a very very 
> bad user experience. From a practical standpoint, this means that a single 
> deployment cannot really support the MTLS draft and have in-browser 
> JavaScript clients using authorization code at the same time. 
> 
> In order to address the conflict here, I'd propose that the MTLS draft 
> introduce a new optional AS metadata parameter that is an MTLS enabled token 
> endpoint alias. Clients that are doing MTLS client authentication and/or 
> certificate bound access tokens would/should/must use the alternative token 
> endpoint when present in the AS's metadata. While all other clients continue 
> to use the standard token endpoint as they always have. This would allow for 
> an AS to deploy an alternative token endpoint alias on a distinct host or 
> port where it will request client certs in the TLS handshake for OAuth 
> clients that use it while keeping the regular token endpoint as it normally 
> is for other clients, especially in-browser JavaScript clients. 
> 
> Thoughts, objections, agreements, etc., on this proposal?
> 
> PS Bikeshedding on a name for the metadata parameter is also welcome. Some 
> ideas to start:
> token_endpoint_mtls_alias
> token_endpoint_mtls
> mtls_token_endpoint_alias
> mtls_token_endpoint
> alt_token_endpoint_mtls
> mtls_token_endpoint_alt
> a_token_endpoint_that_a_client_wanting_to_do_mtls_stuff_a_la_RFC_[TBD]_should_use
> equally_poor_idea_here
> 
> 
> 
> 
> 
> 
> 
> 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

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[John Bradley]

I think that works for those browsers if no certificates are installed 
for the browser.   We should test, but I think if any certificates are 
available to the browser then it will prompt.


John B.


On 12/17/2018 1:52 PM, Neil Madden wrote:

I am currently running a Tomcat instance that I have configured to support, but 
not demand, client certificates using the 
certificateVerification=“optionalNoCA” setting. With this config I am able to 
authenticate a confidential client using mTLS, and yet connecting to the same 
server over HTTPS in either Safari or Chrome on Mac does not prompt me for any 
certificate. I don’t have any client certificates configured in my browser, so 
does this only happen if you do?

Depending on the deployment scenario, it may also be possible to terminate TLS 
at a proxy and use a separate proxy for (intranet) mTLS clients vs public 
clients, but that may not suit every deployment.

— Neil


On 17 Dec 2018, at 20:26, Brian Campbell 
 wrote:

While there's been some disagreement about the specific wording etc., there 
does seem to be general consensus coming out of this WG to, in one form or 
another, recommend against the use of the implicit grant in favor of 
authorization code. In order to follow that recommendation, in-browser 
JavaScript clients will need to use XHR/fetch (and likely CORS) to make 
requests directly to the token endpoint.

Meanwhile there is the MTLS document utilizes TLS client certificates at the 
token endpoint for client authentication and/or certificate bound access 
tokens. The security BCP draft even recommends sender/key constrained access 
tokens and MTLS is close to the only viable way to do that at this time.

Unfortunately, however, these two things don't play very nice together. When a 
browser makes a TLS connection where a client cert is requested by the server 
in the handshake, even when client certificates are optional and even when it's 
fetch/XHR, most/many/all browsers will throw up some kind of certificate 
selection interface to the user.  Which is typically a very very bad user 
experience. From a practical standpoint, this means that a single deployment 
cannot really support the MTLS draft and have in-browser JavaScript clients 
using authorization code at the same time.

In order to address the conflict here, I'd propose that the MTLS draft 
introduce a new optional AS metadata parameter that is an MTLS enabled token 
endpoint alias. Clients that are doing MTLS client authentication and/or 
certificate bound access tokens would/should/must use the alternative token 
endpoint when present in the AS's metadata. While all other clients continue to 
use the standard token endpoint as they always have. This would allow for an AS 
to deploy an alternative token endpoint alias on a distinct host or port where 
it will request client certs in the TLS handshake for OAuth clients that use it 
while keeping the regular token endpoint as it normally is for other clients, 
especially in-browser JavaScript clients.

Thoughts, objections, agreements, etc., on this proposal?

PS Bikeshedding on a name for the metadata parameter is also welcome. Some 
ideas to start:
token_endpoint_mtls_alias
token_endpoint_mtls
mtls_token_endpoint_alias
mtls_token_endpoint
alt_token_endpoint_mtls
mtls_token_endpoint_alt
a_token_endpoint_that_a_client_wanting_to_do_mtls_stuff_a_la_RFC_[TBD]_should_use
equally_poor_idea_here







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

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

[Filip Skokan]

Correct. If there are certs installed on the device the browsers are likely 
going to prompt. 

Having at least one CA configured together with optional_no_ca (even if its a 
CA noone ever has certs for) additionally omits the prompt for some client 
configurations. 

Odesláno z iPhonu

17. 12. 2018 v 23:10, John Bradley :

> I think that works for those browsers if no certificates are installed for 
> the browser.   We should test, but I think if any certificates are available 
> to the browser then it will prompt.
> 
> John B.
> 
> 
>> On 12/17/2018 1:52 PM, Neil Madden wrote:
>> I am currently running a Tomcat instance that I have configured to support, 
>> but not demand, client certificates using the 
>> certificateVerification=“optionalNoCA” setting. With this config I am able 
>> to authenticate a confidential client using mTLS, and yet connecting to the 
>> same server over HTTPS in either Safari or Chrome on Mac does not prompt me 
>> for any certificate. I don’t have any client certificates configured in my 
>> browser, so does this only happen if you do?
>> 
>> Depending on the deployment scenario, it may also be possible to terminate 
>> TLS at a proxy and use a separate proxy for (intranet) mTLS clients vs 
>> public clients, but that may not suit every deployment.
>> 
>> — Neil
>> 
>>> On 17 Dec 2018, at 20:26, Brian Campbell 
>>>  wrote:
>>> 
>>> While there's been some disagreement about the specific wording etc., there 
>>> does seem to be general consensus coming out of this WG to, in one form or 
>>> another, recommend against the use of the implicit grant in favor of 
>>> authorization code. In order to follow that recommendation, in-browser 
>>> JavaScript clients will need to use XHR/fetch (and likely CORS) to make 
>>> requests directly to the token endpoint.
>>> 
>>> Meanwhile there is the MTLS document utilizes TLS client certificates at 
>>> the token endpoint for client authentication and/or certificate bound 
>>> access tokens. The security BCP draft even recommends sender/key 
>>> constrained access tokens and MTLS is close to the only viable way to do 
>>> that at this time.
>>> 
>>> Unfortunately, however, these two things don't play very nice together. 
>>> When a browser makes a TLS connection where a client cert is requested by 
>>> the server in the handshake, even when client certificates are optional and 
>>> even when it's fetch/XHR, most/many/all browsers will throw up some kind of 
>>> certificate selection interface to the user.  Which is typically a very 
>>> very bad user experience. From a practical standpoint, this means that a 
>>> single deployment cannot really support the MTLS draft and have in-browser 
>>> JavaScript clients using authorization code at the same time.
>>> 
>>> In order to address the conflict here, I'd propose that the MTLS draft 
>>> introduce a new optional AS metadata parameter that is an MTLS enabled 
>>> token endpoint alias. Clients that are doing MTLS client authentication 
>>> and/or certificate bound access tokens would/should/must use the 
>>> alternative token endpoint when present in the AS's metadata. While all 
>>> other clients continue to use the standard token endpoint as they always 
>>> have. This would allow for an AS to deploy an alternative token endpoint 
>>> alias on a distinct host or port where it will request client certs in the 
>>> TLS handshake for OAuth clients that use it while keeping the regular token 
>>> endpoint as it normally is for other clients, especially in-browser 
>>> JavaScript clients.
>>> 
>>> Thoughts, objections, agreements, etc., on this proposal?
>>> 
>>> PS Bikeshedding on a name for the metadata parameter is also welcome. Some 
>>> ideas to start:
>>> token_endpoint_mtls_alias
>>> token_endpoint_mtls
>>> mtls_token_endpoint_alias
>>> mtls_token_endpoint
>>> alt_token_endpoint_mtls
>>> mtls_token_endpoint_alt
>>> a_token_endpoint_that_a_client_wanting_to_do_mtls_stuff_a_la_RFC_[TBD]_should_use
>>> equally_poor_idea_here
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 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