t;
>
> *From:* OAuth on behalf of Filip Skokan <
> panva...@gmail.com>
> *Date:* Tuesday, February 12, 2019 at 1:13 PM
> *To:* "Richard Backman, Annabelle"
> *Cc:* Brian Campbell , oauth
>
> *Subject:* Re: [OAUTH-WG] MTLS token endoint & discovery
>
>
>
>
>
> *From: *OAuth on behalf of Filip Skokan <
> panva...@gmail.com>
> *Date: *Tuesday, February 12, 2019 at 1:13 PM
> *To: *"Richard Backman, Annabelle"
> *Cc: *Brian Campbell , oauth
>
> *Subject: *Re: [OAUTH-WG] MTLS token endoint & discovery
ken_endpoint_auth_methods_supported).
>
>
>
> --
>
> Annabelle Richard Backman
>
> AWS Identity
>
>
>
>
>
> *From: *OAuth on behalf of Brian Campbell
>
> *Date: *Tuesday, February 12, 2019 at 10:58 AM
> *To: *Dominick Baier
> *Cc: *oauth
> *Sub
lf
of Brian Campbell
<mailto:bcampbell=40pingidentity@dmarc.ietf.org>
Date: Tuesday, February 12, 2019 at 10:58 AM
To: Dominick Baier <mailto:dba...@leastprivilege.com>
Cc: oauth <mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] MTLS token endoint & discovery
Thanks
Perhaps it's due to my own lack of imagination but I don't see any new
vectors or how the existing mitigations don't work here too. Please propose
some text though, if there's something that should be in the document.
On Tue, Feb 12, 2019 at 8:50 AM Justin Richer wrote:
> At the moment, I like t
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.
At the moment, I like this suggestion. It feels a little … funny … but that
might be just because it’s different from what we had before.
We’ll need to have a clear security considerations discussion about this
though, as it does add another vector for a mix-up attack. I doubt that at this
stag
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 impa
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
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
10 matches
Mail list logo
