I can easily see Research and education publishing self signed certs in meta-data that is then used for client authentication and other things. I don’t want to limit this to only CA issued certs where the client_id is in the DN. Client_id tend not to be domain names currently. Looking up a raw key provided via JWK in registration based on client_id will be one way that people will use this. Passing the cert is seen as just a way of passing the key to many people.
I also understand the desire in ACE to save bytes. If you are using self signed certs then including the client_id in the cert vs as a parameter is a bit of a no op re size. Perhaps if there is a common pattern we could document a IoT profile where ca issued cert is used and what it would look like. I have concerns that this may open a can of worms around what the CN would be and the interpretations of use extensions if this is flagged as something other than a host cert. What do devices do now when they are issued certs. Is there a common standard or is it by manufacturer. My main concern would be to not hold up what should be a simple spec for the server to server case, but am willing to accommodate IoT if possible. Regards John B. > On Oct 28, 2016, at 5:31 PM, Brian Campbell <bcampb...@pingidentity.com> > wrote: > > Not wanting to add more meta parameters was a motivation. Also not being sure > of how to enumerate the possible approaches. My thinking was also that there > are a lot of factors involved and that it'd probably be better left to > service documentation to describe things like what authorities are trusted > and what the client to cert binding is. Like I said, we can look at adding > more metadata, if there's some consensus to do so. But I worry that it'll > just be bloat that doesn't really add value. > > I also think that, in many situations, it's unlikely that a cert will contain > a client id anywhere as subject information. A client id is scoped to a > particular authorization server and it's hard to imagine a CA issuing a cert > with an identifier that's only meaningful in the context of some other entity > like that. Maybe in a more closed system where the AS and an organizational > CA are both in the same management/administrative domain but not in the more > general case. > > > > On Wed, Oct 26, 2016 at 8:42 PM, Vladimir Dzhuvinov <vladi...@connect2id.com > <mailto: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 <mailto:vladi...@connect2id.com> > >> wrote: > >> Superb, I welcome that! > >> > >> Regarding https://tools.ietf.org/html/draft-campbell-oauth-tls- > >> <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 <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>> <brian.d.campb...@gmail.com > >> <mailto:brian.d.campb...@gmail.com>>, "John Bradley" <ve7...@ve7jtb.com > >> <mailto:ve7...@ve7jtb.com>> <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 > >> listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > >> <http://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
