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

[Sergey Beryozkin]

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:

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 > 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 > 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 

On Nov 3, 2016, at 8:51 AM, Justin Richer > 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


On 11/3/2016 8:48 AM, Jim Manico wrote:

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 > 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 

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

[Samuel Erdtman]

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  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  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
>
> On Nov 3, 2016, at 8:51 AM, Justin Richer  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
>
> On 11/3/2016 8:48 AM, Jim Manico wrote:
>
> 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  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
>
> On 11/2/2016 5:03 PM, Brian Campbell wrote:
>
>
> On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman  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 

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

[Jim Manico]

> 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 > > 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
>>
>> On Nov 3, 2016, at 8:51 AM, Justin Richer > > 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
>>>
>>>
>>> On 11/3/2016 8:48 AM, Jim Manico wrote:
 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 > 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
>
>
> On 11/2/2016 5:03 PM, Brian Campbell wrote:
>>
>> On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman
>> > 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.
>> 

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

[Justin Richer]

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  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
> 
> On Nov 3, 2016, at 8:51 AM, Justin Richer  > 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
>> 
>> On 11/3/2016 8:48 AM, Jim Manico wrote:
>>> 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 >> > 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
 
 On 11/2/2016 5:03 PM, Brian Campbell wrote:
> 
> On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman  > 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 

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

[Jim Manico]

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  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
> 
>> On 11/3/2016 8:48 AM, Jim Manico wrote:
>> 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  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
>>> 
 On 11/2/2016 5:03 PM, Brian Campbell wrote:
 
> On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman  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. 
 
 
 
 ___
 OAuth mailing list
 OAuth@ietf.org
 https://www.ietf.org/mailman/listinfo/oauth
>>> 
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
> 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Jim Manico]

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  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
> 
>> On 11/2/2016 5:03 PM, Brian Campbell wrote:
>> 
>>> On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman  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. 
>> 
>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Justin Richer]

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 > 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.




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth