>From my point of view, the cleaner solution is using existing fields for what they are well suited rather than inventing new ones.
On Fri, Nov 11, 2016 at 1:21 PM, Samuel Erdtman <sam...@erdtman.se> wrote: > You are right one could absolutely use the jwks or jwks_uri attribute, but > from my point of view that would be a workaround. > I would prefer that x5u, x5c and/or x5t was directly available in the > client registration request not via jwks. This would be a cleaner solution. > > Best Regards > Samuel > > On Fri, 11 Nov 2016 at 19:13, Brian Campbell <bcampb...@pingidentity.com> > wrote: > >> 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
