As part of the client’s registered data model. At least, based on how our own implementation works (where we support client_secret_basic, private_key_jwt, etc), that’s where we’d check to see if the client was supposed to be using TLS auth or not.
We don’t let clients switch away from their registered auth mechanism. — Justin > On Nov 13, 2016, at 2:21 PM, Torsten Lodderstedt <tors...@lodderstedt.net> > wrote: > > Justin, > > Am 13.11.2016 um 13:39 schrieb Justin Richer: >> Torsten, I believe this is intended to be triggered by the tls_client_auth >> value specified in §3. > > in the token request? > >> >> Nit on that section, the field name for the client metadata in RFC7591 is >> token_endpoint_auth_method, the _supported version is from the corresponding >> discovery document. >> >> — Justin >> > Torsten. >>> On Nov 13, 2016, at 12:31 PM, Torsten Lodderstedt <tors...@lodderstedt.net >>> <mailto:tors...@lodderstedt.net>> wrote: >>> >>> 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: <mailto:internet-dra...@ietf.org>internet-dra...@ietf.org >>>>> <mailto: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 >>>>> <mailto:brian.d.campb...@gmail.com>>, "John Bradley" <ve7...@ve7jtb.com >>>>> <mailto: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 >>>>> >>>>> <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/ >>>>> <https://datatracker.ietf.org/doc/draft-campbell-oauth-tls-client-auth/> >>>>> Htmlized: >>>>> https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00 >>>>> <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 >>>>> <http://tools.ietf.org/>. >>>>> >>>>> The IETF Secretariat >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> <https://www.ietf.org/mailman/listinfo/oauth> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://www.ietf.org/mailman/listinfo/oauth> >> >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
