+1 Phil
> On Nov 4, 2016, at 6:11 PM, John Bradley <ve7...@ve7jtb.com> wrote: > > 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> 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
