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

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,

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

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

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

>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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)

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

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

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

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 >

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

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

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

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

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

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

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

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

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

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

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

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

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

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