heartb...@yahoo.com,alfabet...@yahoo.com,rafal.rog...@aol.com,rogalarafa...@gmail.com,aidis_addict@outlook.beHeartGrtz
W wtorek, 12 lutego 2019, 07:01:41 CET,
napisał(-a):
Send OAuth mailing list submissions to
oauth@ietf.org
To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/oauth
or, via email, send a message with subject or body 'help' to
oauth-requ...@ietf.org
You can reach the person managing the list at
oauth-ow...@ietf.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."
Today's Topics:
1. Re: MTLS token endoint & discovery (Dominick Baier)
--
Message: 1
Date: Mon, 11 Feb 2019 22:01:04 -0800
From: Dominick Baier
To: Brian Campbell
Cc: oauth
Subject: Re: [OAUTH-WG] MTLS token endoint & discovery
Message-ID:
Content-Type: text/plain; charset="utf-8"
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
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
>> *Date:* 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
>>
>>
>>
>> And I'm honestly really struggling to see what
