Wouldn't the existing jwks/jwks_uri client metadata parameters suffice? Perhaps some guidance in this document about that is warranted. But I don't believe anything new is needed for that case.
On Nov 11, 2016 9:41 AM, "Samuel Erdtman" <sam...@erdtman.se> wrote: > Just a quick comment, see inline > > On Thu, Nov 3, 2016 at 1:41 PM, 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. >> >> 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. >> > Should this specification then extend the dynamic registration > specification (https://tools.ietf.org/html/rfc7591) with the certificate > parameter to actually do the registration or is that another document? > > >> I do think that more examples and guidance are warranted, though, to help >> AS developers. >> >> -- 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
