Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

From: Brian Campbell <[email-masked]>
Date: Wed, 2 Nov 2016 15:03:16 -0600

On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman <[email-masked]> wrote:

>
> I agree it is written so that the connection to the certificate is
> implicitly required but I think it would be better if it was explicit
> written since the lack of a connection would result in a potential security
> hole.
>

That's fair. I agree it can be made more explicit and that it be good to do
so.

> When it comes to the client_id I think subject common name or maybe
> subject serial numbers will be the common location, and I think an example
> would be valuable.
>
>

In my experience and the way we built support for mutual TLS OAuth client
auth the client_id value does not appear in the certificate anywhere. I'm
not saying it can't happen but don't think it's particularly common.

I can look at adding some examples, if there's some consensus that they'd
be useful and this document moves forward.

>
> I´m not saying it is a bad Idea just that I would prefer if it was not a
> MUST.
> With very limited addition of code it is just as easy to get the
> certificate attribute for client id as it is to get it from the HTTP
> request data (at least in java). I also think that with the requirement to
> match the incoming certificate in some way one has to read out the
> certificate that was used to establish the connection to do some kind of
> matching.
>
>
Getting data out of the certificate isn't a concern. I just believe that
the constancy of having the client id parameter is worth the potential
small amount duplicate data in some cases. It's just a -00 draft though and
if the WG wants to proceed with this document, we seek further input and
work towards some consensus.

---

From: Justin Richer <[email-masked]>
Date: Thu, 3 Nov 2016 08:41:55 -0400

I agree that the client_id is unlikely to be found inside the 
certificate itself. The client_id is issued by the authorization server 
for the client to use at that single AS. The certificate is issued by 
the CA for the client to use on any connection. The AS and CA are not 
likely to be the same system in most deployments. The client will use 
the same cert across multiple connections, possibly multiple AS's, but 
the same isn't true of the client_id.

Additionally, I think we want to allow for a binding of a self-signed 
certificate using dynamic registration, much the way that we already 
allow binding of a client-generated JWK today.

I do think that more examples and guidance are warranted, though, to 
help AS developers.

  -- Justin

On 11/2/2016 5:03 PM, Brian Campbell wrote:
>
> On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     implicitly required but I think it would be better if it was
>     explicit written since the lack of a connection would result in a
>     potential security hole.
>
>
> That's fair. I agree it can be made more explicit and that it be good 
> to do so.
>
>     When it comes to the client_id I think subject common name or
>     maybe subject serial numbers will be the common location, and I
>     think an example would be valuable.
>
>
> In my experience and the way we built support for mutual TLS OAuth 
> client auth the client_id value does not appear in the certificate 
> anywhere. I'm not saying it can't happen but don't think it's 
> particularly common.
>
> I can look at adding some examples, if there's some consensus that 
> they'd be useful and this document moves forward.
>
>
>     I´m not saying it is a bad Idea just that I would prefer if it was
>     not a MUST.
>     certificate attribute for client id as it is to get it from the
>     HTTP request data (at least in java). I also think that with the
>     requirement to match the incoming certificate in some way one has
>     to read out the certificate that was used to establish the
>     connection to do some kind of matching.
>
>
> Getting data out of the certificate isn't a concern. I just believe 
> that the constancy of having the client id parameter is worth the 
> potential small amount duplicate data in some cases. It's just a -00 
> draft though and if the WG wants to proceed with this document, we 
> seek further input and work towards some consensus.
>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Jim Manico <[email-masked]>
Date: Thu, 3 Nov 2016 08:48:41 -0400

Just to be clear, the relationship should more like...

AS issues public key to clients, or client sends public key to AS. The authorities job is NOT to give the client the public key, but to sign the public key for authenticity. It's bad practice to accept the full cert (pub key+signature) from an authority. If an authority is creating your public key, they are also creating your private key.... bad.

> The client will use the same cert across multiple connections, possibly multiple AS's, but the same isn't true of the client_id. 

This seems like a bad idea. I suggest a separate key/signature for each service.
--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

> On Nov 3, 2016, at 8:41 AM, Justin Richer <[email-masked]> wrote:
> 
> I agree that the client_id is unlikely to be found inside the certificate itself. The client_id is issued by the authorization server for the client to use at that single AS. The certificate is issued by the CA for the client to use on any connection. The AS and CA are not likely to be the same system in most deployments. The client will use the same cert across multiple connections, possibly multiple AS's, but the same isn't true of the client_id. 
> Additionally, I think we want to allow for a binding of a self-signed certificate using dynamic registration, much the way that we already allow binding of a client-generated JWK today. 
> I do think that more examples and guidance are warranted, though, to help AS developers.
> 
>  -- Justin
> 
>>> I agree it is written so that the connection to the certificate is implicitly required but I think it would be better if it was explicit written since the lack of a connection would result in a potential security hole.
>> 
>> That's fair. I agree it can be made more explicit and that it be good to do so. 
>> 
>>  
>>> When it comes to the client_id I think subject common name or maybe subject serial numbers will be the common location, and I think an example would be valuable.
>>>  
>> 
>> In my experience and the way we built support for mutual TLS OAuth client auth the client_id value does not appear in the certificate anywhere. I'm not saying it can't happen but don't think it's particularly common. 
>> 
>> I can look at adding some examples, if there's some consensus that they'd be useful and this document moves forward. 
>> 
>>  
>>> 
>>> I´m not saying it is a bad Idea just that I would prefer if it was not a MUST. 
>>> With very limited addition of code it is just as easy to get the certificate attribute for client id as it is to get it from the HTTP request data (at least in java). I also think that with the requirement to match the incoming certificate in some way one has to read out the certificate that was used to establish the connection to do some kind of matching.
>>> 
>> 
>> Getting data out of the certificate isn't a concern. I just believe that the constancy of having the client id parameter is worth the potential small amount duplicate data in some cases. It's just a -00 draft though and if the WG wants to proceed with this document, we seek further input and work towards some consensus. 
>> 
>> 
>>

---

From: Justin Richer <[email-masked]>
Date: Thu, 3 Nov 2016 08:51:13 -0400

Yes, I elided the certificate issuance process. The point remains the 
same: you're not going to be submitting a CSR to the same party you're 
getting your client_id from, usually. If the draft assumes that, then 
it's incredibly limiting.

Do people really use separate TLS client certs for separate connections 
in the wild? I've personally never seen that. What I've seen is that a 
piece of software gets its certificate that it uses to make whatever 
connections it needs to make.

  -- Justin

On 11/3/2016 8:48 AM, Jim Manico wrote:
> AS issues public key to clients, or client sends public key to AS. The 
> authorities job is NOT to give the client the public key, but to sign 
> the public key for authenticity. It's bad practice to accept the full 
> cert (pub key+signature) from an authority. If an authority is 
> creating your public key, they are also creating your private key.... bad.
>
> > The client will use the same cert across multiple connections, 
> possibly multiple AS's, but the same isn't true of the client_id.
>
> On Nov 3, 2016, at 8:41 AM, Justin Richer <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> certificate itself. The client_id is issued by the authorization 
>> server for the client to use at that single AS. The certificate is 
>> issued by the CA for the client to use on any connection. The AS and 
>> CA are not likely to be the same system in most deployments. The 
>> client will use the same cert across multiple connections, possibly 
>> multiple AS's, but the same isn't true of the client_id.
>>
>>>     I agree it is written so that the connection to the certificate
>>>     is implicitly required but I think it would be better if it was
>>>     explicit written since the lack of a connection would result in
>>>     a potential security hole.
>>>
>>>
>>>     requirement to match the incoming certificate in some way one
>>>     has to read out the certificate that was used to establish the
>> [email-masked] <mailto:[email-masked]>

---

From: Jim Manico <[email-masked]>
Date: Thu, 3 Nov 2016 10:31:39 -0400

Thanks Justin. I use several security intel services and they all have different cert delivery mechanisms for mutual TLS. It's •rare• for services to let clients choose certs, they are usually assigned to users by each service from my experience.

Aloha,
--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

> On Nov 3, 2016, at 8:51 AM, Justin Richer <[email-masked]> wrote:
> 
> Yes, I elided the certificate issuance process. The point remains the same: you're not going to be submitting a CSR to the same party you're getting your client_id from, usually. If the draft assumes that, then it's incredibly limiting.
> 
> 
> Do people really use separate TLS client certs for separate connections in the wild? I've personally never seen that. What I've seen is that a piece of software gets its certificate that it uses to make whatever connections it needs to make.
> 
> 
>  -- Justin
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 3 Nov 2016 12:32:45 -0400

Jim,

In those circumstances, are the clients generally calling multiple different services? Or just one? For those that call multiple services, are they using multiple (different) client certificates?

I’m not saying the client would issue its own cert in all cases — much more common is what I’ve seen, with clients being assigned a certificate from a trusted CA, and then services that the client talks to being told to trust that CA and also assign the CN/DN of the cert a set of privileges. What I *haven’t* seen is a client being issued multiple certificates to talk to multiple systems. That latter case is common enough in the OAuth world that I wouldn’t want us to paint ourselves in a corner.

 — Justin

> On Nov 3, 2016, at 10:31 AM, Jim Manico <[email-masked]> wrote:
> 
> On Nov 3, 2016, at 8:51 AM, Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> 
>>> On Nov 3, 2016, at 8:41 AM, Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>>>> On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman <[email-masked] <mailto:[email-masked]>> wrote:
>>>>> 
>>>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>>> 
>>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>

---

From: Jim Manico <[email-masked]>
Date: Thu, 3 Nov 2016 12:40:46 -0400

> In those circumstances, are the clients generally calling multiple
different services? Or just one? For those that call multiple services,
are they using multiple (different) client certificates?

Ah, good point. I hear you now.  I personally like the idea of "one cert
per service" so I can selectively manage each access separately, but I
understand where you are coming from and it makes sense.

Thanks for taking the time to respectfully explain your perspective and
provide me with a little education. :)

ALOHA,

Jim Manico

On 11/3/16 12:32 PM, Justin Richer wrote:
> Jim,
>
> In those circumstances, are the clients generally calling multiple
> different services? Or just one? For those that call multiple
> services, are they using multiple (different) client certificates?
>
> I’m not saying the client would issue its own cert in all cases — much
> more common is what I’ve seen, with clients being assigned a
> certificate from a trusted CA, and then services that the client talks
> to being told to trust that CA and also assign the CN/DN of the cert a
> set of privileges. What I *haven’t* seen is a client being issued
> multiple certificates to talk to multiple systems. That latter case is
> common enough in the OAuth world that I wouldn’t want us to paint
> ourselves in a corner.
>
>  — Justin
>
>> On Nov 3, 2016, at 10:31 AM, Jim Manico <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> Thanks Justin. I use several security intel services and they all
>> have different cert delivery mechanisms for mutual TLS. It's •rare•
>> for services to let clients choose certs, they are usually assigned
>> to users by each service from my experience.
>>
>> Aloha,
>> --
>> Jim Manico
>> @Manicode
>> Secure Coding Education
>> +1 (808) 652-3805
>>
>>> Yes, I elided the certificate issuance process. The point remains
>>> the same: you're not going to be submitting a CSR to the same party
>>> you're getting your client_id from, usually. If the draft assumes
>>> that, then it's incredibly limiting.
>>>
>>>
>>> Do people really use separate TLS client certs for separate
>>> connections in the wild? I've personally never seen that. What I've
>>> seen is that a piece of software gets its certificate that it uses
>>> to make whatever connections it needs to make.
>>>
>>>
>>>  -- Justin
>>>
>>>
>>>> AS issues public key to clients, or client sends public key to AS.
>>>> The authorities job is NOT to give the client the public key, but
>>>> to sign the public key for authenticity. It's bad practice to
>>>> accept the full cert (pub key+signature) from an authority. If an
>>>> authority is creating your public key, they are also creating your
>>>> private key.... bad.
>>>>
>>>>> issued by the CA for the client to use on any connection. The AS
>>>>> and CA are not likely to be the same system in most deployments.
>>>>> Additionally, I think we want to allow for a binding of a
>>>>> self-signed certificate using dynamic registration, much the way
>>>>> that we already allow binding of a client-generated JWK today.
>>>>>
>>>>>> On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman
>>>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>
>>>>>>
>>>>>>     I agree it is written so that the connection to the
>>>>>>     certificate is implicitly required but I think it would be
>>>>>>     better if it was explicit written since the lack of a
>>>>>>     connection would result in a potential security hole.
>>>>>>
>>>>>>
>>>>>>     maybe subject serial numbers will be the common location, and
>>>>>>     I think an example would be valuable.
>>>>>>      
>>>>>>
>>>>>>
>>>>>> In my experience and the way we built support for mutual TLS
>>>>>> OAuth client auth the client_id value does not appear in the
>>>>>> certificate anywhere. I'm not saying it can't happen but don't
>>>>>> think it's particularly common.
>>>>>>
>>>>>> I can look at adding some examples, if there's some consensus
>>>>>> that they'd be useful and this document moves forward.
>>>>>>
>>>>>>  
>>>>>>
>>>>>>
>>>>>>     With very limited addition of code it is just as easy to get
>>>>>>     the certificate attribute for client id as it is to get it
>>>>>>     from the HTTP request data (at least in java). I also think
>>>>>>     that with the requirement to match the incoming certificate
>>>>>>     in some way one has to read out the certificate that was used
>>>>>>     to establish the connection to do some kind of matching.
>>>>>>
>>>>>>
>>>>>> Getting data out of the certificate isn't a concern. I just
>>>>>> believe that the constancy of having the client id parameter is
>>>>>> worth the potential small amount duplicate data in some cases.
>>>>>> It's just a -00 draft though and if the WG wants to proceed with
>>>>>> this document, we seek further input and work towards some
>>>>>> consensus.
>>>>>>
>>>>>>
>>>>>>

-- 
Jim Manico
Manicode Security
https://www.manicode.com

---

From: Samuel Erdtman <[email-masked]>
Date: Thu, 3 Nov 2016 17:48:14 +0100

I can see your point, maybe the client_id will not be in the certificate.
If I had an AS I would select to trust one or several CAs and then create
certificate mappings between certificate serial number (or some other
unique attribute in the certificate) and client_id. If I were to bind a
specific certificate to a client_id I lose the flexibility of the PKI
(maybe what you want).

I think multiple certificates might not be a uncommon situation especially
if you call ASs from different organizations because they will trust
different CAs.

//Samuel

On Thu, Nov 3, 2016 at 5:32 PM, Justin Richer <[email-masked]> wrote:

> different services? Or just one? For those that call multiple services, are
> they using multiple (different) client certificates?
>
> more common is what I’ve seen, with clients being assigned a certificate
> from a trusted CA, and then services that the client talks to being told to
> trust that CA and also assign the CN/DN of the cert a set of privileges.
> What I *haven’t* seen is a client being issued multiple certificates to
> talk to multiple systems. That latter case is common enough in the OAuth
> world that I wouldn’t want us to paint ourselves in a corner.
>
>  — Justin
>
> Thanks Justin. I use several security intel services and they all have
> different cert delivery mechanisms for mutual TLS. It's •rare• for services
> to let clients choose certs, they are usually assigned to users by each
> service from my experience.
>
> Aloha,
> --
> Jim Manico
> @Manicode
> Secure Coding Education
> +1 (808) 652-3805
>
> getting your client_id from, usually. If the draft assumes that, then it's
> incredibly limiting.
>
>
> Do people really use separate TLS client certs for separate connections in
> the wild? I've personally never seen that. What I've seen is that a piece
> of software gets its certificate that it uses to make whatever connections
> it needs to make.
>
>
>  -- Justin
>
> authorities job is NOT to give the client the public key, but to sign the
> public key for authenticity. It's bad practice to accept the full cert (pub
> key+signature) from an authority. If an authority is creating your public
> key, they are also creating your private key.... bad.
>
> > The client will use the same cert across multiple connections, possibly
> I agree that the client_id is unlikely to be found inside the certificate
> itself. The client_id is issued by the authorization server for the client
> to use at that single AS. The certificate is issued by the CA for the
> client to use on any connection. The AS and CA are not likely to be the
> same system in most deployments. The client will use the same cert across
> multiple connections, possibly multiple AS's, but the same isn't true of
> the client_id.
>
> certificate using dynamic registration, much the way that we already allow
> binding of a client-generated JWK today.
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 3 Nov 2016 17:11:22 +0000

Hi

In our implementation we support the following scenario:
- the client registers its public certificate during the client registration

- next, mutual/two-way TLS is used, so AccessTokenService tries to 
figure out the client_id. At the moment it assumes the client_id is
(Java) X509Certificate.getSubjectX500Principal().getName().

Next it retrieves a client with this name and compares the TLS 
client/peer certificate against the pre-registered one.

I think it may be interesting to explore further if client_id can become 
optional based on what Samuel said.

For example, indeed I can see how I can update our code to have a 
mapping between some of client certificate's properties and a client id 
stored within a Client registration.

The question is how to find a given Client registration effectively 
given only a certificate, without an optional client_id. One would need 
to have a map between these client certificate attribute and client_id 
or Clients.

Cheers, Sergey

On 03/11/16 16:48, Samuel Erdtman wrote:
> If I had an AS I would select to trust one or several CAs and then
> create certificate mappings between certificate serial number (or some
> other unique attribute in the certificate) and client_id. If I were to
> bind a specific certificate to a client_id I lose the flexibility of the
> PKI (maybe what you want).
>
> I think multiple certificates might not be a uncommon situation
> especially if you call ASs from different organizations because they
> will trust different CAs.
>
> //Samuel
>
>
> On Thu, Nov 3, 2016 at 5:32 PM, Justin Richer <[email-masked]
>     I’m not saying the client would issue its own cert in all cases —
>     much more common is what I’ve seen, with clients being assigned a
>     certificate from a trusted CA, and then services that the client
>     talks to being told to trust that CA and also assign the CN/DN of
>     the cert a set of privileges. What I *haven’t* seen is a client
>     being issued multiple certificates to talk to multiple systems. That
>     latter case is common enough in the OAuth world that I wouldn’t want
>     us to paint ourselves in a corner.
>
>      — Justin
>
>>     have different cert delivery mechanisms for mutual TLS. It's
>>     •rare• for services to let clients choose certs, they are usually
>>     assigned to users by each service from my experience.
>>
>>     Aloha,
>>     --
>>     Jim Manico
>>     @Manicode
>>     Secure Coding Education
>>     +1 (808) 652-3805 <tel:%2B1%20%28808%29%20652-3805>
>>
>>>     the same: you're not going to be submitting a CSR to the same
>>>     party you're getting your client_id from, usually. If the draft
>>>     assumes that, then it's incredibly limiting.
>>>
>>>
>>>     connections in the wild? I've personally never seen that. What
>>>     I've seen is that a piece of software gets its certificate that
>>>     it uses to make whatever connections it needs to make.
>>>
>>>
>>>      -- Justin
>>>
>>>
>>>>     AS issues public key to clients, or client sends public key to
>>>>     AS. The authorities job is NOT to give the client the public
>>>>     key, but to sign the public key for authenticity. It's bad
>>>>     practice to accept the full cert (pub key+signature) from an
>>>>     authority. If an authority is creating your public key, they are
>>>>     also creating your private key.... bad.
>>>>
>>>>     +1 (808) 652-3805 <tel:%2B1%20%28808%29%20652-3805>
>>>>
>>>>>     certificate itself. The client_id is issued by the
>>>>>     authorization server for the client to use at that single AS.
>>>>>     The certificate is issued by the CA for the client to use on
>>>>>     any connection. The AS and CA are not likely to be the same
>>>>>     system in most deployments. The client will use the same cert
>>>>>     across multiple connections, possibly multiple AS's, but the
>>>>>     same isn't true of the client_id.
>>>>>
>>>>>     self-signed certificate using dynamic registration, much the
>>>>>     way that we already allow binding of a client-generated JWK today.
>>>>>
>>>>>>         When it comes to the client_id I think subject common name
>>>>>>         or maybe subject serial numbers will be the common
>>>>>>         location, and I think an example would be valuable.
>>>>>>
>>>>>>
>>>>>>
>>>>>>         With very limited addition of code it is just as easy to
>>>>>>         get the certificate attribute for client id as it is to
>>>>>>         get it from the HTTP request data (at least in java). I
>>>>>>         also think that with the requirement to match the incoming
>>>>>>         certificate in some way one has to read out the
>>>>>>         certificate that was used to establish the connection to
>>>>>>         do some kind of matching.
>>>>>>
>>>>>>
>>>>>>     believe that the constancy of having the client id parameter
>>>>>>     is worth the potential small amount duplicate data in some
>>>>>>     cases. It's just a -00 draft though and if the WG wants to
>>>>>>     proceed with this document, we seek further input and work
>>>>>>     towards some consensus.
>>>>>>
>>>>>>
>>>>>>
>>>>>>     <https://www.ietf.org/mailman/listinfo/oauth>
>>>>>
>>>>>     <https://www.ietf.org/mailman/listinfo/oauth>
>>>
>
>
>
>

-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

---

From: Jim Manico <[email-masked]>
Date: Fri, 4 Nov 2016 13:06:13 -0400

You could also sign the client_id with your private cert and send it
like normal OAuth requests...

But I like the idea of mapping the client_id server-side to the cert as
well.

Now we're talking real security. Bearer tokens are so Q1-2016. :)

Aloha, Jim

On 11/3/16 1:11 PM, Sergey Beryozkin wrote:
> I think it may be interesting to explore further if client_id can
> become optional based on what Samuel said.
>
> mapping between some of client certificate's properties and a client
> id stored within a Client registration.
>
> given only a certificate, without an optional client_id. One would
> need to have a map between these client certificate attribute and
> client_id or Clients.
>
> Cheers, Sergey
>
>
>

-- 
Jim Manico
Manicode Security
https://www.manicode.com

---

From: Brian Campbell <[email-masked]>
Date: Fri, 4 Nov 2016 15:17:54 -0600

few little things inline...

> multiple connections, possibly multiple AS's, but the same isn't true of

You said it better than I.

> binding of a client-generated JWK today.
Binding the client to a self-signed certificate is pretty similar to
binding to the public key. But I agree it should be possible.

The jwks_uri or jwks client registration metadata parameters are well
suited to convey such info. The JWKs in them can convey the public key
(obviously) but can also can convey a self-signed certificate with the
"x5c" (X.509 Certificate Chain) parameter.

> I do think that more examples and guidance are warranted, though, to help

Noted.

---

From: John Bradley <[email-masked]>
Date: Fri, 4 Nov 2016 22:11:19 -0300

I can easily see Research and education publishing self signed certs in meta-data that is then used for client authentication and other things.
I don’t want to limit this to only CA issued certs where the client_id is in the DN.    Client_id tend not to be domain names currently.
Looking up a raw key  provided via JWK in registration based on client_id will be one way that people will use this.   Passing the cert is seen as just a way of passing the key to many people.

I also understand the desire in ACE to save bytes.

If you are using self signed certs then including the client_id in the cert vs as a parameter is a bit of a no op re size.

Perhaps if there is a common pattern we could document a IoT profile where ca issued cert is used and what it would look like.

I have concerns that this may open a can of worms around what the CN would be and the interpretations of use extensions if this is flagged as something other than a host cert.    What do devices do now when they are issued certs.  Is there a common standard or is it by manufacturer.

My main concern would be to not hold up what should be a simple spec for the server to server case, but am willing to accommodate IoT if possible.

Regards
John B.

> On Oct 28, 2016, at 5:31 PM, Brian Campbell <[email-masked]> wrote:
> 
> Not wanting to add more meta parameters was a motivation. Also not being sure of how to enumerate the possible approaches. My thinking was also that there are a lot of factors involved and that it'd probably be better left to service documentation to describe things like what authorities are trusted and what the client to cert binding is. Like I said, we can look at adding more metadata, if there's some consensus to do so. But I worry that it'll just be bloat that doesn't really add value. 
> 
> I also think that, in many situations, it's unlikely that a cert will contain a client id anywhere as subject information. A client id is scoped to a particular authorization server and it's hard to imagine a CA issuing a cert with an identifier that's only meaningful in the context of some other entity like that. Maybe in a more closed system where the AS and an organizational CA are both in the same management/administrative domain but not in the more general case.   
> 
> 
> 
> On Wed, Oct 26, 2016 at 8:42 PM, Vladimir Dzhuvinov <[email-masked] <mailto:[email-masked]>> wrote:
> I see. Do you reckon the AS could simply probe the likely cert places
> for containing the client_id? My reasoning is that there aren't that
> many places where you could stick the client_id (let me know if I'm
> wrong). If the AS is in doubt it will respond with invalid_client. I'm
> starting to think this can work quite well. No extra meta param will be
> needed (of which we have enough already).
> 
> On 22/10/16 01:51, Brian Campbell wrote:
> > I did consider something like that but stopped short of putting it in the
> > -00 document. I'm not convinced that some metadata around it would really
> > contribute to interop one way or the other. I also wanted to get the basic
> > concept written down before going too far into the weeds. But I'd be open
> > to adding something along those lines in future revisions, if there's some
> > consensus that it'd be useful.
> >
> > On Mon, Oct 17, 2016 at 2:47 AM, Vladimir Dzhuvinov <[email-masked] <mailto:[email-masked]>
> >> wrote:
> >> Superb, I welcome that!
> >>
> >> Regarding https://tools.ietf.org/html/draft-campbell-oauth-tls- <https://tools.ietf.org/html/draft-campbell-oauth-tls->
> >> client-auth-00#section-5.2 :
> >>
> >> My concern is that the choice of how to bind the client identity is left
> >> to implementers, and that may eventually become an interop problem.
> >> Have you considered some kind of an open ended enumeration of the possible
> >> binding methods, and giving them some identifiers or names, so that AS /
> >> OPs can advertise them in their metadata, and clients register accordingly?
> >>
> >> For example:
> >>
> >> "tls_client_auth_bind_methods_supported" : [ "subject_alt_name_match",
> >> "subject_public_key_info_match" ]
> >>
> >>
> >> Cheers,
> >>
> >> Vladimir
> >>
> >> On 10/10/16 23:59, John Bradley wrote:
> >>
> >> At the request of the OpenID Foundation Financial Services API Working group, Brian Campbell and I have documented
> >> mutual TLS client authentication.   This is something that lots of people do in practice though we have never had a spec for it.
> >>
> >> The Banks want to use it for some server to server API use cases being driven by new open banking regulation.
> >>
> >> The largest thing in the draft is the IANA registration of “tls_client_auth” Token Endpoint authentication method for use in Registration and discovery.
> >>
> >> The trust model is intentionally left open so that you could use a “common name” and a restricted list of CA or a direct lookup of the subject public key against a reregistered value,  or something in between.
> >>
> >> I hope that this is non controversial and the WG can adopt it quickly.
> >>
> >> Regards
> >> John B.
> >>
> >>
> >>
> >>
> >>
> >> Begin forwarded message:
> >>
> >> From: [email-masked] <mailto:[email-masked]>
> >> Subject: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt
> >> Date: October 10, 2016 at 5:44:39 PM GMT-3
> >> To: "Brian Campbell" <[email-masked] <mailto:[email-masked]>> <[email-masked] <mailto:[email-masked]>>, "John Bradley" <[email-masked] <mailto:[email-masked]>> <[email-masked] <mailto:[email-masked]>>
> >>
> >>
> >> A new version of I-D, draft-campbell-oauth-tls-client-auth-00.txt
> >> has been successfully submitted by John Bradley and posted to the
> >> IETF repository.
> >>
> >> Name:                draft-campbell-oauth-tls-client-auth
> >> Revision:    00
> >> Title:               Mutual X.509 Transport Layer Security (TLS) Authentication for OAuth Clients
> >> Document date:       2016-10-10
> >> Group:               Individual Submission
> >> Pages:               5
> >> URL:            https://www.ietf.org/internet-drafts/draft-campbell-oauth-tls-client-auth-00.txt <https://www.ietf.org/internet-drafts/draft-campbell-oauth-tls-client-auth-00.txt>
> >> Status:         https://datatracker.ietf.org/doc/draft-campbell-oauth-tls-client-auth/ <https://datatracker.ietf.org/doc/draft-campbell-oauth-tls-client-auth/>
> >> Htmlized:       https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00 <https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00>
> >>
> >>
> >> Abstract:
> >>   This document describes X.509 certificates as OAuth client
> >>   credentials using Transport Layer Security (TLS) mutual
> >>   authentication as a mechanism for client authentication to the
> >>   authorization server's token endpoint.
> >>
> >>
> >>
> >>
> >> Please note that it may take a couple of minutes from the time of submission
> >> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> >>
> >> The IETF Secretariat
> >>
> >>
> >>
> >>
> >> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth <http://www.ietf.org/mailman/listinfo/oauth>
> >>
> >>
> >>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Fri, 4 Nov 2016 18:14:23 -0700

+1

Phil

> On Nov 4, 2016, at 6:11 PM, John Bradley <[email-masked]> wrote:
> 
>>> On Wed, Oct 26, 2016 at 8:42 PM, Vladimir Dzhuvinov <[email-masked]> wrote:
>>> > On Mon, Oct 17, 2016 at 2:47 AM, Vladimir Dzhuvinov <[email-masked]
>>> >> wrote:
>>> >> Superb, I welcome that!
>>> >>
>>> >> Regarding https://tools.ietf.org/html/draft-campbell-oauth-tls-
>>> >> From: [email-masked]
>>> >> To: "Brian Campbell" <[email-masked]> <[email-masked]>, "John Bradley" <[email-masked]> <[email-masked]>
>>> >>
>>> >>
>>> >> URL:            https://www.ietf.org/internet-drafts/draft-campbell-oauth-tls-client-auth-00.txt
>>> >> Status:         https://datatracker.ietf.org/doc/draft-campbell-oauth-tls-client-auth/
>>> >> Htmlized:       https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00
>>> >>
>>> >>
>>> >> Abstract:
>>> >> until the htmlized version and diff are available at tools.ietf.org.
>>> >>
>>> >> The IETF Secretariat
>>> >>
>>> >>
>>> >>
>>> >>

---

From: Samuel Erdtman <[email-masked]>
Date: Mon, 7 Nov 2016 17:43:28 +0100

Phil, what is your +1 referring to?

//Samuel

On Sat, Nov 5, 2016 at 2:14 AM, Phil Hunt (IDM) <[email-masked]>
wrote:

> I can easily see Research and education publishing self signed certs in
> meta-data that is then used for client authentication and other things.
> I don’t want to limit this to only CA issued certs where the client_id is
> in the DN.    Client_id tend not to be domain names currently.
> Looking up a raw key  provided via JWK in registration based on client_id
> will be one way that people will use this.   Passing the cert is seen as
> just a way of passing the key to many people.
>
> If you are using self signed certs then including the client_id in the
> cert vs as a parameter is a bit of a no op re size.
>
> Perhaps if there is a common pattern we could document a IoT profile where
> ca issued cert is used and what it would look like.
>
> I have concerns that this may open a can of worms around what the CN would
> be and the interpretations of use extensions if this is flagged as
> something other than a host cert.    What do devices do now when they are
> issued certs.  Is there a common standard or is it by manufacturer.
>
> My main concern would be to not hold up what should be a simple spec for
> the server to server case, but am willing to accommodate IoT if possible.
>
> Regards
> John B.
>
> Not wanting to add more meta parameters was a motivation. Also not being
> sure of how to enumerate the possible approaches. My thinking was also that
> there are a lot of factors involved and that it'd probably be better left
> to service documentation to describe things like what authorities are
> trusted and what the client to cert binding is. Like I said, we can look at
> adding more metadata, if there's some consensus to do so. But I worry that
> it'll just be bloat that doesn't really add value.
>
> I also think that, in many situations, it's unlikely that a cert will
> contain a client id anywhere as subject information. A client id is scoped
> to a particular authorization server and it's hard to imagine a CA issuing
> a cert with an identifier that's only meaningful in the context of some
> other entity like that. Maybe in a more closed system where the AS and an
> organizational CA are both in the same management/administrative domain but
> not in the more general case.
>
>
>
>> >> At the request of the OpenID Foundation Financial Services API Working
>> group, Brian Campbell and I have documented
>> >> mutual TLS client authentication.   This is something that lots of
>> people do in practice though we have never had a spec for it.
>> >>
>> >> The largest thing in the draft is the IANA registration of
>> “tls_client_auth” Token Endpoint authentication method for use in
>> Registration and discovery.
>> >>
>> >> The trust model is intentionally left open so that you could use a
>> “common name” and a restricted list of CA or a direct lookup of the subject
>> public key against a reregistered value,  or something in between.
>> >>
>> >> To: "Brian Campbell" <[email-masked]> <
>> [email-masked]>, "John Bradley" <[email-masked]> <
>> [email-masked]>
>> >>
>> >>
>> >> URL:            https://www.ietf.org/internet-
>> drafts/draft-campbell-oauth-tls-client-auth-00.txt
>> >> Status:         https://datatracker.ietf.org/
>> doc/draft-campbell-oauth-tls-client-auth/

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Mon, 7 Nov 2016 09:11:53 -0800

John's comments

Phil

> On Nov 7, 2016, at 8:43 AM, Samuel Erdtman <[email-masked]> wrote:
> 
>> On Sat, Nov 5, 2016 at 2:14 AM, Phil Hunt (IDM) <[email-masked]> wrote:
>> +1
>> 
>> Phil
>>

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Thu, 10 Nov 2016 22:10:54 +0200

> - the client registers its public certificate during the client

Did you extend the standard client reg API for this purpose?

How does the cert registration actually take place?

-- 
Vladimir Dzhuvinov :: [email-masked]

---

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 10 Nov 2016 21:57:54 +0000

On 10/11/16 21:57, Sergey Beryozkin wrote:
> On 10/11/16 20:10, Vladimir Dzhuvinov wrote:
>>
>>
> No. Should there be an option in the client reg API ?
>>
> The encoded certificate is an optional property of the Client class
> which is part of the larger OAuth2 model. The clients are registered out
> of band - the assumption that the product integrating our model will let
> the admins upload a certificate associated with a given client,
> alongside all the other information one would typically allocate at a
> client registration time via some UI page.
> In a particular integration instance I'm aware of no such option to
> upload the certs is offered yet
>
> Sergey
>>
>>>

-- 
Sergey Beryozkin

Talend Community Coders

---

From: Samuel Erdtman <[email-masked]>
Date: Fri, 11 Nov 2016 17:41:17 +0100

Just a quick comment, see inline

> binding of a client-generated JWK today.
Should this specification then extend the dynamic registration
specification (https://tools.ietf.org/html/rfc7591) with the certificate
parameter to actually do the registration or is that another document?

---

From: Brian Campbell <[email-masked]>
Date: Fri, 11 Nov 2016 11:13:05 -0700

Wouldn't the existing jwks/jwks_uri client metadata parameters suffice?
Perhaps some guidance in this document about that is warranted. But I don't
believe anything new is needed for that case.

---

From: Samuel Erdtman <[email-masked]>
Date: Fri, 11 Nov 2016 20:17:13 +0000

You are absolutely right one could use the

---

From: Samuel Erdtman <[email-masked]>
Date: Fri, 11 Nov 2016 20:21:30 +0000

You are right one could absolutely use the jwks or jwks_uri attribute, but
from my point of view that would be a workaround.
I would prefer that x5u, x5c and/or x5t was directly available in the
client registration request not via jwks. This would be a cleaner solution.

Best Regards
Samuel

---

From: Brian Campbell <[email-masked]>
Date: Fri, 11 Nov 2016 14:54:14 -0700

>From my point of view, the cleaner solution is using existing fields for
what they are well suited rather than inventing new ones.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 13 Nov 2016 12:31:22 +0900

Hi John and Brian,

thanks for writting this draft.

One question: how does the AS determine the authentication method is TLS 
authentication? I think you assume this is defined by the 
client-specific policy, independent of whether the client is registered 
automatically or manually. Would you mind to explicitely state this in 
the draft?

best regards,
Torsten.

Am 11.10.2016 um 05:59 schrieb John Bradley:
> “common name” and a restricted list of CA or a direct lookup of the 
> subject public key against a reregistered value,  or something in between.
>
>> *From: [email-masked] <mailto:[email-masked]>
>> *Subject: **New Version Notification for 
>> draft-campbell-oauth-tls-client-auth-00.txt*
>> *Date: *October 10, 2016 at 5:44:39 PM GMT-3
>> *To: *"Brian Campbell" <[email-masked] 
>> <mailto:[email-masked]>>, "John Bradley" 
>> <[email-masked] <mailto:[email-masked]>>
>>
>>
>> Name:draft-campbell-oauth-tls-client-auth
>> Revision:00
>> Title:Mutual X.509 Transport Layer Security (TLS) Authentication for 
>> OAuth Clients
>> Document date:2016-10-10
>> Group:Individual Submission
>> Pages:5
>> URL: 
>> https://www.ietf.org/internet-drafts/draft-campbell-oauth-tls-client-auth-00.txt
>> Status: 
>> https://datatracker.ietf.org/doc/draft-campbell-oauth-tls-client-auth/
>> Htmlized: 
>> https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00
>>
>>
>> Abstract:
>> until the htmlized version and diff are available at tools.ietf.org 
>> <http://tools.ietf.org>.
>>
>> The IETF Secretariat
>>
>
>
>

---

From: Justin Richer <[email-masked]>
Date: Sun, 13 Nov 2016 13:39:55 +0900

Torsten, I believe this is intended to be triggered by the tls_client_auth value specified in §3. 

Nit on that section, the field name for the client metadata in RFC7591 is token_endpoint_auth_method, the _supported version is from the corresponding discovery document.

 — Justin

> On Nov 13, 2016, at 12:31 PM, Torsten Lodderstedt <[email-masked]> wrote:
> 
> Hi John and Brian,
> 
> One question: how does the AS determine the authentication method is TLS authentication? I think you assume this is defined by the client-specific policy, independent of whether the client is registered automatically or manually. Would you mind to explicitely state this in the draft?
> 
> best regards,
> Torsten.
> 
>>> From:  <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>
>>> To: "Brian Campbell" < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>>, "John Bradley" <[email-masked] <mailto:[email-masked]>>
>>> 
>>>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 13 Nov 2016 14:21:12 +0900

Justin,

> tls_client_auth value specified in §3.

in the token request?

>
> Nit on that section, the field name for the client metadata in RFC7591 
> is token_endpoint_auth_method, the _supported version is from the 
> corresponding discovery document.
>
>  — Justin
>
Torsten.
>> On Nov 13, 2016, at 12:31 PM, Torsten Lodderstedt 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Hi John and Brian,
>>
>> One question: how does the AS determine the authentication method is 
>> TLS authentication? I think you assume this is defined by the 
>> client-specific policy, independent of whether the client is 
>> registered automatically or manually. Would you mind to explicitely 
>> state this in the draft?
>>
>> best regards,
>> Torsten.
>>
>>> At the request of the OpenID Foundation Financial Services API 
>>> Working group, Brian Campbell and I have documented
>>> The Banks want to use it for some server to server API use cases 
>>> being driven by new open banking regulation.
>>>
>>>> *From: [email-masked]
>>>> *To: *"Brian Campbell" <[email-masked]>, "John Bradley" 
>>>> Title:Mutual X.509 Transport Layer Security (TLS) Authentication 
>>>> for OAuth Clients
>>>> Document date:2016-10-10
>>>> <http://tools.ietf.org/>.
>>>>
>>>> The IETF Secretariat
>>>>
>>>
>>>
>>>

---

From: Justin Richer <[email-masked]>
Date: Sun, 13 Nov 2016 14:24:29 +0900

As part of the client’s registered data model. At least, based on how our own implementation works (where we support client_secret_basic, private_key_jwt, etc), that’s where we’d check to see if the client was supposed to be using TLS auth or not.

We don’t let clients switch away from their registered auth mechanism.

 — Justin

> On Nov 13, 2016, at 2:21 PM, Torsten Lodderstedt <[email-masked]> wrote:
> 
> Justin,
> 
>>> On Nov 13, 2016, at 12:31 PM, Torsten Lodderstedt <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hi John and Brian,
>>> 
>>>>> To: "Brian Campbell" <[email-masked] <mailto:[email-masked]>>, "John Bradley" <[email-masked] <mailto:[email-masked]>>
>>>>> 
>>>>>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 13 Nov 2016 14:59:21 +0900

I understand. My point is different: the text seems to assume everybody 
is using client registration, but that's not the case. I would like to 
point out it makes sense to explicitely state the assumption that it is 
determined by client policy (indepedent of the way this policy is 
established).

Am 13.11.2016 um 14:24 schrieb Justin Richer:
> As part of the client’s registered data model. At least, based on how 
> our own implementation works (where we support client_secret_basic, 
> private_key_jwt, etc), that’s where we’d check to see if the client 
> was supposed to be using TLS auth or not.
>
>> On Nov 13, 2016, at 2:21 PM, Torsten Lodderstedt 
>>> Nit on that section, the field name for the client metadata in 
>>> RFC7591 is token_endpoint_auth_method, the _supported version is 
>>> from the corresponding discovery document.
>>>
>>>  — Justin
>>>
>> Torsten.
>>>> One question: how does the AS determine the authentication method 
>>>> is TLS authentication? I think you assume this is defined by the 
>>>>> “common name” and a restricted list of CA or a direct lookup of 
>>>>> the subject public key against a reregistered value,  or something 
>>>>> in between.
>>>>>
>>>>>> *To: *"Brian Campbell" <[email-masked]>, "John 
>>>>>> Bradley" <[email-masked] <mailto:[email-masked]>>
>>>>>>
>>>>>>

---

From: Brian Campbell <[email-masked]>
Date: Sun, 13 Nov 2016 14:21:03 -0700

Yes, the intend is that the authentication method is determined by client
policy regardless of whether the client was dynamically registered or
statically configured or whatever. I can make that point more explicit in
future revisions of the draft.

On Sat, Nov 12, 2016 at 10:59 PM, Torsten Lodderstedt <
[email-masked]> wrote:

> I understand. My point is different: the text seems to assume everybody is
> using client registration, but that's not the case. I would like to point
> out it makes sense to explicitely state the assumption that it is
> As part of the client’s registered data model. At least, based on how our
> own implementation works (where we support client_secret_basic,
> private_key_jwt, etc), that’s where we’d check to see if the client was
> supposed to be using TLS auth or not.
>
> Nit on that section, the field name for the client metadata in RFC7591 is
> token_endpoint_auth_method, the _supported version is from the
> On Nov 13, 2016, at 12:31 PM, Torsten Lodderstedt <
> <[email-masked]>[email-masked]> wrote:
>
> Hi John and Brian,
>
> authentication? I think you assume this is defined by the client-specific
> policy, independent of whether the client is registered automatically or
> manually. Would you mind to explicitely state this in the draft?
>
> best regards,
> Torsten.
>
> mutual TLS client authentication.   This is something that lots of people
> do in practice though we have never had a spec for it.
>
> The trust model is intentionally left open so that you could use a “common
> name” and a restricted list of CA or a direct lookup of the subject public
> key against a reregistered value,  or something in between.
>
> *From: * <[email-masked]>[email-masked]
> *To: *"Brian Campbell" < <[email-masked]>
> [email-masked]>, "John Bradley" < <[email-masked]>
> [email-masked]>
>
>
> <https://www.ietf.org/internet-drafts/draft-campbell-oauth-tls-client-auth-00.txt>
> <https://datatracker.ietf.org/doc/draft-campbell-oauth-tls-client-auth/>
> <https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00>

---

From: Brian Campbell <[email-masked]>
Date: Sun, 13 Nov 2016 14:25:33 -0700

Good catch Justin, thank you. I got the filed names switched around for
some reason.

---

From: Justin Richer <[email-masked]>
Date: Mon, 14 Nov 2016 09:26:37 +0900

Right — this is a fine way to put it. RFC7591 defines a client model where RFC6749 didn’t. Ideally all that metadata would’ve been in the original spec, but it’s not. It doesn’t matter whether the client was registered dynamically or statically, it just matters that the AS knows what to expect from a given client.

 — Justin

> On Nov 14, 2016, at 6:21 AM, Brian Campbell <[email-masked]> wrote:
> 
> Yes, the intend is that the authentication method is determined by client policy regardless of whether the client was dynamically registered or statically configured or whatever. I can make that point more explicit in future revisions of the draft. 
> 
> On Sat, Nov 12, 2016 at 10:59 PM, Torsten Lodderstedt <[email-masked] <mailto:[email-masked]>> wrote:
> I understand. My point is different: the text seems to assume everybody is using client registration, but that's not the case. I would like to point out it makes sense to explicitely state the assumption that it is determined by client policy (indepedent of the way this policy is established).
> 
> 
>>> On Nov 13, 2016, at 2:21 PM, Torsten Lodderstedt <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Justin,
>>> 
>>>>> On Nov 13, 2016, at 12:31 PM, Torsten Lodderstedt < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>> wrote:
>>>>> 
>>>>> Hi John and Brian,
>>>>> 
>>>>>>> To: "Brian Campbell" < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>>, "John Bradley" < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>>
>>>>>>> 
>>>>>>> 
>>>>>>> URL:             <https://www.ietf.org/internet-drafts/draft-campbell-oauth-tls-client-auth-00.txt>https://www.ietf.org/internet-drafts/draft-campbell-oauth-tls-client-auth-00.txt <https://www.ietf.org/internet-drafts/draft-campbell-oauth-tls-client-auth-00.txt>
>>>>>>> Status:          <https://datatracker.ietf.org/doc/draft-campbell-oauth-tls-client-auth/>https://datatracker.ietf.org/doc/draft-campbell-oauth-tls-client-auth/ <https://datatracker.ietf.org/doc/draft-campbell-oauth-tls-client-auth/>
>>>>>>> Htmlized:        <https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00>https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00 <https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00>
>>>>>>> 
>>>>>>> 
>>>>>>> Abstract:

---

From: Samuel Erdtman <[email-masked]>
Date: Tue, 15 Nov 2016 18:02:01 +0100

The reason I think it is a workaround to use the jwks or jwks_uri is that
you would then wrap the x5u, x5c and/or x5t in a jwk object that you do not
really need. So the implementation needs to be aware of how to create and
read jwk even though it will not use any of the jwk data.

With that said, lets see what others think.

On Fri, Nov 11, 2016 at 10:54 PM, Brian Campbell <[email-masked]

>> You are right one could absolutely use the jwks or jwks_uri attribute,
>> but from my point of view that would be a workaround.
>>> certificate itself. The client_id is issued by the authorization server for
>>> the client to use at that single AS. The certificate is issued by the CA
>>> for the client to use on any connection. The AS and CA are not likely to be
>>> the same system in most deployments. The client will use the same cert
>>> across multiple connections, possibly multiple AS's, but the same isn't
>>> true of the client_id.
>>>
>>> specification (https://tools.ietf.org/html/rfc7591) with the
>>> certificate parameter to actually do the registration or is that another
>>> document?
>>>
>>>
>>> anywhere. I'm not saying it can't happen but don't think it's particularly
>>> common.
>>>

---

From: Samuel Erdtman <[email-masked]>
Date: Tue, 15 Nov 2016 18:14:09 +0100

Torstens questions triggers another question from me.

If we have an AS that can handle both certificate client auth and client
secret, how does the AS know that it should ask for client certificate on
the TLS layer.

It was a while since I last read the TLS specification and it might have
changed but if i remember correctly client certificates are provided in
initial handshake or in re-negotiate and it is only provided on request by
the server.

If this is still true the AS would need to first get the token request, see
that this is a client that authenticates with certificate and request a TLS
re-negotiate to get the certificate authentication and a re-submission of
the token request since we cannot trust the data first submitted.

Are I missing something obvious, or is this something that needs to be
defined?

//Samuel

On Mon, Nov 14, 2016 at 1:26 AM, Justin Richer <[email-masked]> wrote:

> Right — this is a fine way to put it. RFC7591 defines a client model where
> RFC6749 didn’t. Ideally all that metadata would’ve been in the original
> spec, but it’s not. It doesn’t matter whether the client was registered
> dynamically or statically, it just matters that the AS knows what to expect
> from a given client.
>
>  — Justin
>

---

From: Brian Campbell <[email-masked]>
Date: Tue, 15 Nov 2016 16:08:56 -0700

Yes, I believe you are correct. Client certificates are provided in the
handshake (initial or renegotiated) at the request of the server. If the
server asks and the client doesn't provide a cert, it's up to the server
whether to continue or about the handshake.

There seem to be a number of different ways of trying to deal with this
(not strictly for this OAuth case but similar situations).

The AS could always request client certs but allow connections to proceed
regardless. Then check for certs for appropriate clients while processing
token requests.  I guess there's a little overhead in the handshake with
this for all the connections that won't present a cert. But not a ton. The
main drawback is that some/many browsers have UI that will prompt users to
choose a cert even when they don't have any. And the user experience can be
very bad or confusing as a result.

The token endpoint could be on a different host or port which always
requests client certs. Still allow connections to proceed regardless and
check the client credentials at the OAuth layer. Pretty similar to the
above but avoids the usability issues with end users because it's only at
the token endpoint.

Trying renegotiation after the application sees that it's a token request
or that it's a token request from a client id that's configured for mutual
TLS is another approach. In my own limited experience with this kind of
thing, however, this approach can be kind of flaky. And your point about
the initial data not being trustworthy is legitimate. I'm not sure if it
really matters in this case. I don't know. And signaling to resubmit is
another issue all together.

There are probably other approaches too but those are the things I've seen
or can imagine. In all (or nearly all) the deployments of our stuff that I
know about that deal with mutual TLS, some variation of the second option
is used.

All this seem like implementation/deployment details though and I'm
hesitant to try and define how to do it in this doc. Maybe providing some
guidance. I'm not exactly sure how to do that though.

On Tue, Nov 15, 2016 at 10:14 AM, Samuel Erdtman <[email-masked]> wrote:

> If this is still true the AS would need to first get the token request,
> see that this is a client that authenticates with certificate and request a
> TLS re-negotiate to get the certificate authentication and a re-submission
> of the token request since we cannot trust the data first submitted.
>
>> Right — this is a fine way to put it. RFC7591 defines a client model
>> where RFC6749 didn’t. Ideally all that metadata would’ve been in the
>> original spec, but it’s not. It doesn’t matter whether the client was
>> registered dynamically or statically, it just matters that the AS knows
>> what to expect from a given client.
>>
>>  — Justin
>>

---

From: Brian Campbell <[email-masked]>
Date: Tue, 15 Nov 2016 17:03:49 -0700

Whoops, "about" at the end of the 1st paragraph should be "abort".

On Nov 16, 2016 8:08 AM, "Brian Campbell" <[email-masked]>
wrote:

>>> Yes, the intend is that the authentication method is determined by
>>> client policy regardless of whether the client was dynamically registered
>>> or statically configured or whatever. I can make that point more explicit
>>> in future revisions of the draft.
>>>
>>>> automatically or manually. Would you mind to explicitely state this in the
>>>> draft?
>>>>
>>>> best regards,
>>>> Torsten.
>>>>

---

From: Samuel Erdtman <[email-masked]>
Date: Thu, 24 Nov 2016 07:48:52 +0100

+1 on providing guidance.

On Wed, Nov 16, 2016 at 12:08 AM, Brian Campbell <[email-masked]

---

From: Jim Manico <[email-masked]>
Date: Thu, 24 Nov 2016 09:42:15 +0100

Dude. You're freaking awesome. Thanks for this insight.

--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

> On Nov 24, 2016, at 7:48 AM, Samuel Erdtman <[email-masked]> wrote:
> 
>> On Wed, Nov 16, 2016 at 12:08 AM, Brian Campbell <[email-masked]> wrote:
>> Yes, I believe you are correct. Client certificates are provided in the handshake (initial or renegotiated) at the request of the server. If the server asks and the client doesn't provide a cert, it's up to the server whether to continue or about the handshake. 
>> 
>> There seem to be a number of different ways of trying to deal with this (not strictly for this OAuth case but similar situations).
>> 
>> The AS could always request client certs but allow connections to proceed regardless. Then check for certs for appropriate clients while processing token requests.  I guess there's a little overhead in the handshake with this for all the connections that won't present a cert. But not a ton. The main drawback is that some/many browsers have UI that will prompt users to choose a cert even when they don't have any. And the user experience can be very bad or confusing as a result.
>> 
>> The token endpoint could be on a different host or port which always requests client certs. Still allow connections to proceed regardless and check the client credentials at the OAuth layer. Pretty similar to the above but avoids the usability issues with end users because it's only at the token endpoint. 
>> 
>> Trying renegotiation after the application sees that it's a token request or that it's a token request from a client id that's configured for mutual TLS is another approach. In my own limited experience with this kind of thing, however, this approach can be kind of flaky. And your point about the initial data not being trustworthy is legitimate. I'm not sure if it really matters in this case. I don't know. And signaling to resubmit is another issue all together. 
>> 
>> There are probably other approaches too but those are the things I've seen or can imagine. In all (or nearly all) the deployments of our stuff that I know about that deal with mutual TLS, some variation of the second option is used. 
>> 
>> All this seem like implementation/deployment details though and I'm hesitant to try and define how to do it in this doc. Maybe providing some guidance. I'm not exactly sure how to do that though.  
>> 
>> 
>> 
>>> If we have an AS that can handle both certificate client auth and client secret, how does the AS know that it should ask for client certificate on the TLS layer.
>>> 
>>> It was a while since I last read the TLS specification and it might have changed but if i remember correctly client certificates are provided in initial handshake or in re-negotiate and it is only provided on request by the server.
>>> 
>>> If this is still true the AS would need to first get the token request, see that this is a client that authenticates with certificate and request a TLS re-negotiate to get the certificate authentication and a re-submission of the token request since we cannot trust the data first submitted.
>>> 
>>> Are I missing something obvious, or is this something that needs to be defined?
>>> 
>>> //Samuel
>>> 
>>> 
>>> 
>>> 
>>> 
>>>  
>>> 
>>>>>> On Sat, Nov 12, 2016 at 10:59 PM, Torsten Lodderstedt <[email-masked]> wrote:
>>>>>>>>>>>> To: "Brian Campbell" <[email-masked]>, "John Bradley" <[email-masked]>
>>>>>>>>>>>> 
>>>>>>>>>>>>