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

[Vladimir Dzhuvinov <[e-mail]>]

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 <[e-mail]
>> 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: [e-mail]
>> 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" <[e-mail]> <[e-mail]>, "John Bradley" <[e-mail]> <[e-mail]>
>>
>>
>> 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 [e-mail]://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>