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> >> <brian.d.campb...@gmail.com>, "John Bradley" <ve7...@ve7jtb.com> >> <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 >> 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
