<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Thu, Oct 27, 2016 at 12:00 AM, Samuel Erdtman <span dir="ltr"><<a href="mailto:samuel@erdtman.se" target="_blank">samuel@erdtman.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div>I think it is awesome that this document has been written since this is one of the solutions that exists in the wild.<br><br></div></div></div></div></blockquote><div><br></div><div>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.<br></div><div> <br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div></div>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.<br></div></div></div></blockquote><br>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.   </div><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><br></div>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 (<a href="https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-03" target="_blank">https://tools.ietf.org/html/d<wbr>raft-ietf-ace-oauth-authz-03</a>) we would like to lessen the duplicated information as much as possible.<span class="gmail-m_6794794654778339671gmail-HOEnZb"></span><br></div></div></blockquote><div><br></div><div>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. <br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br> </div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><span class="gmail-m_6794794654778339671gmail-HOEnZb"><font color="#888888"></font></span></div><span class="gmail-m_6794794654778339671gmail-HOEnZb"><font color="#888888">//Samuel<br><div><div><br></div></div></font></span></div><div class="gmail-m_6794794654778339671gmail-HOEnZb"><div class="gmail-m_6794794654778339671gmail-h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 27, 2016 at 4:42 AM, Vladimir Dzhuvinov <span dir="ltr"><<a href="mailto:vladimir@connect2id.com" target="_blank">vladimir@connect2id.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I see. Do you reckon the AS could simply probe the likely cert places<br>
for containing the client_id? My reasoning is that there aren't that<br>
many places where you could stick the client_id (let me know if I'm<br>
wrong). If the AS is in doubt it will respond with invalid_client. I'm<br>
starting to think this can work quite well. No extra meta param will be<br>
needed (of which we have enough already).<br>
<br>
On 22/10/16 01:51, Brian Campbell wrote:<br>
> I did consider something like that but stopped short of putting it in the<br>
> -00 document. I'm not convinced that some metadata around it would really<br>
> contribute to interop one way or the other. I also wanted to get the basic<br>
> concept written down before going too far into the weeds. But I'd be open<br>
> to adding something along those lines in future revisions, if there's some<br>
> consensus that it'd be useful.<br>
<div><div class="gmail-m_6794794654778339671gmail-m_-7521386281464221212h5">><br>
> On Mon, Oct 17, 2016 at 2:47 AM, Vladimir Dzhuvinov <<a href="mailto:vladimir@connect2id.com" target="_blank">vladimir@connect2id.com</a><br>
>> wrote:<br>
>> Superb, I welcome that!<br>
>><br>
>> Regarding <a href="https://tools.ietf.org/html/draft-campbell-oauth-tls-" rel="noreferrer" target="_blank">https://tools.ietf.org/html/dr<wbr>aft-campbell-oauth-tls-</a><br>
>> client-auth-00#section-5.2 :<br>
>><br>
>> My concern is that the choice of how to bind the client identity is left<br>
>> to implementers, and that may eventually become an interop problem.<br>
>> Have you considered some kind of an open ended enumeration of the possible<br>
>> binding methods, and giving them some identifiers or names, so that AS /<br>
>> OPs can advertise them in their metadata, and clients register accordingly?<br>
>><br>
>> For example:<br>
>><br>
>> "tls_client_auth_bind_methods_<wbr>supported" : [ "subject_alt_name_match",<br>
>> "subject_public_key_info_match<wbr>" ]<br>
>><br>
>><br>
>> Cheers,<br>
>><br>
>> Vladimir<br>
>><br>
>> On 10/10/16 23:59, John Bradley wrote:<br>
>><br>
>> At the request of the OpenID Foundation Financial Services API Working group, Brian Campbell and I have documented<br>
>> mutual TLS client authentication.   This is something that lots of people do in practice though we have never had a spec for it.<br>
>><br>
>> The Banks want to use it for some server to server API use cases being driven by new open banking regulation.<br>
>><br>
>> The largest thing in the draft is the IANA registration of “tls_client_auth” Token Endpoint authentication method for use in Registration and discovery.<br>
>><br>
>> 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.<br>
>><br>
>> I hope that this is non controversial and the WG can adopt it quickly.<br>
>><br>
>> Regards<br>
>> John B.<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> Begin forwarded message:<br>
>><br>
>> From: <a href="mailto:internet-drafts@ietf.org" target="_blank">internet-drafts@ietf.org</a><br>
>> Subject: New Version Notification for draft-campbell-oauth-tls-clien<wbr>t-auth-00.txt<br>
>> Date: October 10, 2016 at 5:44:39 PM GMT-3<br>
</div></div>>> To: "Brian Campbell" <<a href="mailto:brian.d.campbell@gmail.com" target="_blank">brian.d.campbell@gmail.com</a>> <<a href="mailto:brian.d.campbell@gmail.com" target="_blank">brian.d.campbell@gmail.com</a>>, "John Bradley" <<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>> <<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>><br>
<div class="gmail-m_6794794654778339671gmail-m_-7521386281464221212HOEnZb"><div class="gmail-m_6794794654778339671gmail-m_-7521386281464221212h5">>><br>
>><br>
>> A new version of I-D, draft-campbell-oauth-tls-clien<wbr>t-auth-00.txt<br>
>> has been successfully submitted by John Bradley and posted to the<br>
>> IETF repository.<br>
>><br>
>> Name:                draft-campbell-oauth-tls-clien<wbr>t-auth<br>
>> Revision:    00<br>
>> Title:               Mutual X.509 Transport Layer Security (TLS) Authentication for OAuth Clients<br>
>> Document date:       2016-10-10<br>
>> Group:               Individual Submission<br>
>> Pages:               5<br>
>> URL:            <a href="https://www.ietf.org/internet-drafts/draft-campbell-oauth-tls-client-auth-00.txt" rel="noreferrer" target="_blank">https://www.ietf.org/internet-<wbr>drafts/draft-campbell-oauth-tl<wbr>s-client-auth-00.txt</a><br>
>> Status:         <a href="https://datatracker.ietf.org/doc/draft-campbell-oauth-tls-client-auth/" rel="noreferrer" target="_blank">https://datatracker.ietf.org/<wbr>doc/draft-campbell-oauth-tls-c<wbr>lient-auth/</a><br>
>> Htmlized:       <a href="https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00" rel="noreferrer" target="_blank">https://tools.ietf.org/html/d<wbr>raft-campbell-oauth-tls-client<wbr>-auth-00</a><br>
>><br>
>><br>
>> Abstract:<br>
>>   This document describes X.509 certificates as OAuth client<br>
>>   credentials using Transport Layer Security (TLS) mutual<br>
>>   authentication as a mechanism for client authentication to the<br>
>>   authorization server's token endpoint.<br>
>><br>
>><br>
>><br>
>><br>
>> Please note that it may take a couple of minutes from the time of submission<br>
>> until the htmlized version and diff are available at <a href="http://tools.ietf.org" rel="noreferrer" target="_blank">tools.ietf.org</a>.<br>
>><br>
>> The IETF Secretariat<br>
>><br>
>><br>
>><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> OAuth mailing listOAuth@ietf.orghttps://<a href="http://www.ietf.org/mailman/listinfo/oauth" rel="noreferrer" target="_blank">www.<wbr>ietf.org/mailman/listinfo/oaut<wbr>h</a><br>
>><br>
>><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> OAuth mailing list<br>
>> <a href="mailto:OAuth@ietf.org" target="_blank">OAuth@ietf.org</a><br>
>> <a href="https://www.ietf.org/mailman/listinfo/oauth" rel="noreferrer" target="_blank">https://www.ietf.org/mailman/l<wbr>istinfo/oauth</a><br>
>><br>
>><br>
<br>
<br>
</div></div><br>______________________________<wbr>_________________<br>
OAuth mailing list<br>
<a href="mailto:OAuth@ietf.org" target="_blank">OAuth@ietf.org</a><br>
<a href="https://www.ietf.org/mailman/listinfo/oauth" rel="noreferrer" target="_blank">https://www.ietf.org/mailman/l<wbr>istinfo/oauth</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>