few little things inline... On Thu, Nov 3, 2016 at 6:41 AM, Justin Richer <jric...@mit.edu> wrote:
> I agree that the client_id is unlikely to be found inside the certificate > itself. The client_id is issued by the authorization server for the client > to use at that single AS. The certificate is issued by the CA for the > client to use on any connection. The AS and CA are not likely to be the > same system in most deployments. The client will use the same cert across > multiple connections, possibly multiple AS's, but the same isn't true of > the client_id. > You said it better than I. > Additionally, I think we want to allow for a binding of a self-signed > certificate using dynamic registration, much the way that we already allow > binding of a client-generated JWK today. > Binding the client to a self-signed certificate is pretty similar to binding to the public key. But I agree it should be possible. The jwks_uri or jwks client registration metadata parameters are well suited to convey such info. The JWKs in them can convey the public key (obviously) but can also can convey a self-signed certificate with the "x5c" (X.509 Certificate Chain) parameter. > I do think that more examples and guidance are warranted, though, to help > AS developers. > Noted. > -- Justin > > On 11/2/2016 5:03 PM, Brian Campbell wrote: > > > On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman <sam...@erdtman.se> wrote: > >> >> I agree it is written so that the connection to the certificate is >> implicitly required but I think it would be better if it was explicit >> written since the lack of a connection would result in a potential security >> hole. >> > > That's fair. I agree it can be made more explicit and that it be good to > do so. > > > >> When it comes to the client_id I think subject common name or maybe >> subject serial numbers will be the common location, and I think an example >> would be valuable. >> >> > > In my experience and the way we built support for mutual TLS OAuth client > auth the client_id value does not appear in the certificate anywhere. I'm > not saying it can't happen but don't think it's particularly common. > > I can look at adding some examples, if there's some consensus that they'd > be useful and this document moves forward. > > > >> >> I´m not saying it is a bad Idea just that I would prefer if it was not a >> MUST. >> With very limited addition of code it is just as easy to get the >> certificate attribute for client id as it is to get it from the HTTP >> request data (at least in java). I also think that with the requirement to >> match the incoming certificate in some way one has to read out the >> certificate that was used to establish the connection to do some kind of >> matching. >> >> > Getting data out of the certificate isn't a concern. I just believe that > the constancy of having the client id parameter is worth the potential > small amount duplicate data in some cases. It's just a -00 draft though and > if the WG wants to proceed with this document, we seek further input and > work towards some consensus. > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
