te: *Wednesday, February 6, 2019 at 11:30 AM
> *To: *"Richard Backman, Annabelle"
> *Cc: *"Richard Backman, Annabelle" , oauth <
> oauth@ietf.org>
> *Subject: *Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser
> clients using the token endpoint
>
>
ufficiently 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 Metad
t (e.g., “Authorization Server Metadata
>> Extensions for mTLS Hybrids”) and get mTLS out the door.
>>
>>
>>
>> --
>>
>> Annabelle Richard Backman
>>
>> AWS Identity
>>
>>
>>
>>
>>
>> *From: *OAuth on behalf
ta
> Extensions for mTLS Hybrids”) and get mTLS out the door.
>
>
>
> --
>
> Annabelle Richard Backman
>
> AWS Identity
>
>
>
>
>
> *From: *OAuth on behalf of Brian Campbell
>
> *Date: *Monday, February 4, 2019 at 5:28 AM
> *To: *"Richard Backman, An
Filip did some testing along these lines awhile back. Although I think he
was more focused on the other side of things by instructing the fetch/XHR
request to omit sending credentials. The behavior he saw was that he wasn't
able to suppress the certificate selection prompting as expected or hoped.
Server Metadata Extensions
> for mTLS Hybrids”) and get mTLS out the door.
>
> --
> Annabelle Richard Backman
> AWS Identity
>
>
> From: OAuth on behalf of Brian Campbell
>
> Date: Monday, February 4, 2019 at 5:28 AM
> To: "Richard Backman, Annabelle"
I’m less and less convinced that a redirect is the best way to do this.
I was reading the WHATWG Fetch spec yesterday, in particular the entries about
CORS, and realised that for cross-origin requests TLS client certificates are
treated as credentials just like cookies:
https://fetch.spec.whatw
+1 to David. If it’s a redirect, 307 is more appropriate. It’s up to the AS to
decide if the client should do MTLS or not, if there’s an option.
— Justin
On Feb 4, 2019, at 12:17 PM, David Waite
mailto:da...@alkaline-solutions.com>> wrote:
My understanding is that a permanent redirect would be
My understanding is that a permanent redirect would be telling the client (and
any other clients getting cached results from an intermediary) to now stop
using the original endpoint in perpetuity for all cases. I don’t think that is
appropriate (in the general case) for an endpoint with request
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 an
Yeah, probably.
On Sat, Feb 2, 2019 at 12:39 AM Neil Madden
wrote:
> If we go down the 307 route, shouldn’t it rather be a 308 (permanent)
> redirect? It seems unnecessary for the client to keep trying the original
> endpoint or have to remember cache-control/expires timeouts.
>
> — Neil
>
> On
If we go down the 307 route, shouldn’t it rather be a 308 (permanent) redirect?
It seems unnecessary for the client to keep trying the original endpoint or
have to remember cache-control/expires timeouts.
— Neil
> On 2 Feb 2019, at 00:03, Richard Backman, Annabelle
> wrote:
>
> Confusion fr
12 matches
Mail list logo
