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 there should be text saying that there MUST be a binding and provide the default solution e.g. client_id as subject common name. 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 (https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-03) we would like to lessen the duplicated information as much as possible. //Samuel On Thu, Oct 27, 2016 at 4:42 AM, Vladimir Dzhuvinov <vladi...@connect2id.com > wrote: > 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 > >> > >> > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
