You are absolutely right one could use the 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
