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

[Samuel Erdtman]

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

> From my point of view, the cleaner solution is using existing fields for
> what they are well suited rather than inventing new ones.
>
> On Fri, Nov 11, 2016 at 1:21 PM, Samuel Erdtman  wrote:
>
>> 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
>>
>> On Fri, 11 Nov 2016 at 19:13, Brian Campbell 
>> wrote:
>>
>>> 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.
>>>
>>> On Nov 11, 2016 9:41 AM, "Samuel Erdtman"  wrote:
>>>
>>> Just a quick comment, see inline
>>>
>>> On Thu, Nov 3, 2016 at 1:41 PM, 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.
>>>
>>> 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?
>>>
>>>
>>> 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 listOAuth@ietf.orghttps://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

[Torsten Lodderstedt]

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:
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: *internet-dra...@ietf.org 
*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" >, "John Bradley" 
>



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


The IETF Secretariat





___
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

[Brian Campbell]

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

On Fri, Nov 11, 2016 at 1:21 PM, Samuel Erdtman  wrote:

> 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
>
> On Fri, 11 Nov 2016 at 19:13, Brian Campbell 
> wrote:
>
>> 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.
>>
>> On Nov 11, 2016 9:41 AM, "Samuel Erdtman"  wrote:
>>
>> Just a quick comment, see inline
>>
>> On Thu, Nov 3, 2016 at 1:41 PM, 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.
>>
>> 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?
>>
>>
>> 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 listOAuth@ietf.orghttps://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

[Samuel Erdtman]

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

On Fri, 11 Nov 2016 at 19:13, Brian Campbell 
wrote:

> 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.
>
> On Nov 11, 2016 9:41 AM, "Samuel Erdtman"  wrote:
>
> Just a quick comment, see inline
>
> On Thu, Nov 3, 2016 at 1:41 PM, 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.
>
> 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?
>
>
> 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 listOAuth@ietf.orghttps://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

[Samuel Erdtman]

You are absolutely right one could use the

On Fri, 11 Nov 2016 at 19:13, Brian Campbell 
wrote:

> 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.
>
> On Nov 11, 2016 9:41 AM, "Samuel Erdtman"  wrote:
>
> Just a quick comment, see inline
>
> On Thu, Nov 3, 2016 at 1:41 PM, 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.
>
> 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?
>
>
> 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 listOAuth@ietf.orghttps://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

[Brian Campbell]

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.

On Nov 11, 2016 9:41 AM, "Samuel Erdtman"  wrote:

> Just a quick comment, see inline
>
> On Thu, Nov 3, 2016 at 1:41 PM, 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.
>>
> 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?
>
>
>> 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 listOAuth@ietf.orghttps://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

[Samuel Erdtman]

Just a quick comment, see inline

On Thu, Nov 3, 2016 at 1:41 PM, 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.
>
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?


> 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 listOAuth@ietf.orghttps://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

[Brian Campbell]

few little things inline...

On Thu, Nov 3, 2016 at 6: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.
>

You said it better than I.


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

Noted.


>  -- 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 listOAuth@ietf.orghttps://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]

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

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

[Brian Campbell]

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

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

[Samuel Erdtman]

Thanks for the reply Brian,

See inline

On Fri, Oct 28, 2016 at 10:56 PM, Brian Campbell  wrote:

>
> On Thu, Oct 27, 2016 at 12:00 AM, Samuel Erdtman 
> wrote:
>
>> I think it is awesome that this document has been written since this is
>> one of the solutions that exists in the wild.
>>
>>
> Thanks. To some extent I was working to codify those existing solutions,
> which is one of the reasons why the specific binding between client and
> certificate is left open ended.
>
>
>
>> However I think that the connection to client (client_id) and certificate
>> could be more clearly specified, at the moment it is exemplified under
>> security considerations. I think there should be text saying that there
>> MUST be a binding and provide the default solution e.g. client_id as
>> subject common name.
>>
>
> I sort of thought the need for connection between client and certificate
> was implicit in the text that is in section 2. But I can work to make the
> language more explicit. As I mentioned in my recent reply to Vladimir, I
> expect client_id as subject common name to be more the exception rather
> than the common case so don't feel it'd be appropriate as a default.
>

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.

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.


>
>
>>
>> Further I would prefer if it was not a MUST to include the client_id in
>> the HTTP request since I think there MUST exist a client binding in the
>> certificate. I think there is no need to have it explicitly in the HTTP
>> request. This might not be a problem for Classic OAuth but when adopted for
>> ACE framework (https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-03)
>> we would like to lessen the duplicated information as much as possible.
>>
>
> There needs to be a binding between the client and certificate but that
> doesn't mean the client id will be in the certificate. Having the client id
> explicitly available in the HTTP request allows the AS to easily identify
> the client independently and consistently from the content of the
> certificate or key and allows the AS to not have to index its client
> storage by some other value. It may lead to a small amount of duplicate
> info in some cases but I believe the consistency is worth it.
>

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.


>
>
>
>>
>>
>>
> //Samuel
>>
>>
>> On Thu, Oct 27, 2016 at 4:42 AM, Vladimir Dzhuvinov <
>> vladi...@connect2id.com> 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 <
>>> vladi...@connect2id.com
>>> >> wrote:
>>> >> Superb, I welcome that!
>>> >>
>>> >> Regarding 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 

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

[Brian Campbell]

On Thu, Oct 27, 2016 at 12:00 AM, Samuel Erdtman  wrote:

> I think it is awesome that this document has been written since this is
> one of the solutions that exists in the wild.
>
>
Thanks. To some extent I was working to codify those existing solutions,
which is one of the reasons why the specific binding between client and
certificate is left open ended.



> However I think that the connection to client (client_id) and certificate
> could be more clearly specified, at the moment it is exemplified under
> security considerations. I think there should be text saying that there
> MUST be a binding and provide the default solution e.g. client_id as
> subject common name.
>

I sort of thought the need for connection between client and certificate
was implicit in the text that is in section 2. But I can work to make the
language more explicit. As I mentioned in my recent reply to Vladimir, I
expect client_id as subject common name to be more the exception rather
than the common case so don't feel it'd be appropriate as a default.


>
> Further I would prefer if it was not a MUST to include the client_id in
> the HTTP request since I think there MUST exist a client binding in the
> certificate. I think there is no need to have it explicitly in the HTTP
> request. This might not be a problem for Classic OAuth but when adopted for
> ACE framework (https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-03)
> we would like to lessen the duplicated information as much as possible.
>

There needs to be a binding between the client and certificate but that
doesn't mean the client id will be in the certificate. Having the client id
explicitly available in the HTTP request allows the AS to easily identify
the client independently and consistently from the content of the
certificate or key and allows the AS to not have to index its client
storage by some other value. It may lead to a small amount of duplicate
info in some cases but I believe the consistency is worth it.



>
>
>
//Samuel
>
>
> On Thu, Oct 27, 2016 at 4:42 AM, Vladimir Dzhuvinov <
> vladi...@connect2id.com> 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 <
>> vladi...@connect2id.com
>> >> wrote:
>> >> Superb, I welcome that!
>> >>
>> >> Regarding 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: internet-dra...@ietf.org
>> >> Subject: New Version Notification for 

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

[Brian Campbell]

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  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 <
> vladi...@connect2id.com
> >> wrote:
> >> Superb, I welcome that!
> >>
> >> Regarding 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: internet-dra...@ietf.org
> >> Subject: New Version Notification for draft-campbell-oauth-tls-clien
> t-auth-00.txt
> >> Date: October 10, 2016 at 5:44:39 PM GMT-3
> >> To: "Brian Campbell"  <
> brian.d.campb...@gmail.com>, "John Bradley"  <
> ve7...@ve7jtb.com>
> >>
> >>
> >> 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
> >> Status: https://datatracker.ietf.org/
> doc/draft-campbell-oauth-tls-client-auth/
> >> Htmlized:   https://tools.ietf.org/html/d
> raft-campbell-oauth-tls-client-auth-00
> >>
> >>
> >> Abstract:
> >>   This document describes X.509 certificates as OAuth client
> >>   credentials using Transport Layer Security (TLS) 

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

[Samuel Erdtman]

I think it is awesome that this document has been written since this is one
of the solutions that exists in the wild.

However I think that the connection to client (client_id) and certificate
could be more clearly specified, at the moment it is exemplified under
security considerations. I think there should be text saying that there
MUST be a binding and provide the default solution e.g. client_id as
subject common name.

Further I would prefer if it was not a MUST to include the client_id in the
HTTP request since I think there MUST exist a client binding in the
certificate. I think there is no need to have it explicitly in the HTTP
request. This might not be a problem for Classic OAuth but when adopted for
ACE framework (https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-03)
we would like to lessen the duplicated information as much as possible.

//Samuel


On Thu, Oct 27, 2016 at 4:42 AM, Vladimir Dzhuvinov  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 <
> vladi...@connect2id.com
> >> wrote:
> >> Superb, I welcome that!
> >>
> >> Regarding 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: internet-dra...@ietf.org
> >> 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"  <
> brian.d.campb...@gmail.com>, "John Bradley"  <
> ve7...@ve7jtb.com>
> >>
> >>
> >> 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
> >> 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:
> >>   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
> >>   

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

[Vladimir Dzhuvinov]

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 > wrote:
>> Superb, I welcome that!
>>
>> Regarding 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: internet-dra...@ietf.org
>> 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"  
>> , "John Bradley"  
>> 
>>
>>
>> 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
>> 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:
>>   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.
>>
>> The IETF Secretariat
>>
>>
>>
>>
>> ___
>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>




smime.p7s
Description: S/MIME Cryptographic Signature
___
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

[Brian Campbell]

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

> Superb, I welcome that!
>
> Regarding 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: internet-dra...@ietf.org
> 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"  
> , "John Bradley"  
> 
>
>
> 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
> 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:
>   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.
>
> The IETF Secretariat
>
>
>
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://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

[Vladimir Dzhuvinov]

Superb, I welcome that!

Regarding
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: internet-dra...@ietf.org
>> 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" , "John Bradley" 
>> 
>>
>>
>> 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
>> 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:
>>   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.
>>
>> The IETF Secretariat
>>
>
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth