Agreed.
> On 20 Feb 2019, at 23:09, John Bradley wrote:
>
> I agree.
>
> If someone really wants separate meta-data nothing stops them from having a
> separate AS with its own meta-data.
>
> John B.
>
>> On 2/20/2019 7:04 PM, Torsten Lodderstedt wrote:
>> +1 for defining an optional mtls en
+1
———
Dominick
On 21. February 2019 at 09:35:35, Dave Tonge (dave.to...@momentumft.co.uk)
wrote:
+1 for mtls_endpoints optional metadata
Dave Tonge
On Thu, 21 Feb 2019 at 00:09, John Bradley wrote:
> I agree.
>
> If someone really wants separate meta-data nothing stops them from having
>
+1 for mtls_endpoints optional metadata
Dave Tonge
On Thu, 21 Feb 2019 at 00:09, John Bradley wrote:
> I agree.
>
> If someone really wants separate meta-data nothing stops them from having
> a separate AS with its own meta-data.
>
> John B.
> On 2/20/2019 7:04 PM, Torsten Lodderstedt wrote:
I agree.
If someone really wants separate meta-data nothing stops them from
having a separate AS with its own meta-data.
John B.
On 2/20/2019 7:04 PM, Torsten Lodderstedt wrote:
+1 for defining an optional mtls endpoints section
I first leaned towards a second metadata file, mainly due to t
+1 for defining an optional mtls endpoints section
I first leaned towards a second metadata file, mainly due to the potential
token endpoint authentication method issue. But adding a secondary metadata
configuration just for this purpose seems a bit over engineered and would take
a lot of norma
+1, great summary
Odesláno z iPhonu
20. 2. 2019 v 16:10, Brian Campbell
:
> The objective is to allow the AS to provide MTLS negotiating endpoints on a
> different host and/or port so that any non-desirable side effects of
> requesting client certificates during the TLS handshake can be avoid
+1 to Brian’s recommendations.
The recommendations provide practical help especially to facilitate real world
migration where bearer and non-bearer must co-exist without confusing end users.
Phil
> On Feb 20, 2019, at 7:10 AM, Brian Campbell
> wrote:
>
> The objective is to allow the AS to
The objective is to allow the AS to provide MTLS negotiating endpoints on a
different host and/or port so that any non-desirable side effects of
requesting client certificates during the TLS handshake can be avoided for
'regular' clients that are not doing any MTLS.
In all likelihood, I'd expect t