<p dir="ltr">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.</p>
<div class="gmail_extra"><br><div class="gmail_quote">On Nov 11, 2016 9:41 AM, "Samuel Erdtman" <<a href="mailto:samuel@erdtman.se">samuel@erdtman.se</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Just a quick comment, see inline<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 3, 2016 at 1:41 PM, Justin Richer <span dir="ltr"><<a href="mailto:jricher@mit.edu" target="_blank">jricher@mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p>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.
<br>
</p>
<p>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. <br></p></div></blockquote><div>Should this specification then extend the dynamic registration specification (<a href="https://tools.ietf.org/html/rfc7591" target="_blank">https://tools.ietf.org/html/<wbr>rfc7591</a>) with the certificate parameter to actually do the registration or is that another document?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><p>
</p>
<p>I do think that more examples and guidance are warranted, though,
to help AS developers.</p><span class="m_3505641874876562717gmail-HOEnZb"><font color="#888888">
<p> -- Justin<br>
</p></font></span><div><div class="m_3505641874876562717gmail-h5">
<br>
<div class="m_3505641874876562717gmail-m_-1237624956419455067moz-cite-prefix">On 11/2/2016 5:03 PM, Brian Campbell
wrote:<br>
</div>
</div></div><blockquote type="cite"><div><div class="m_3505641874876562717gmail-h5">
<div dir="ltr"><br>
<div class="gmail_extra">On Sun, Oct 30, 2016 at 9:27 AM, Samuel
Erdtman <span dir="ltr"><<a href="mailto:samuel@erdtman.se" target="_blank">samuel@erdtman.se</a>></span>
wrote:<br>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<div dir="ltr"><span class="m_3505641874876562717gmail-m_-1237624956419455067gmail-"></span><span class="m_3505641874876562717gmail-m_-1237624956419455067gmail-"></span>
<div class="gmail_extra"><span class="m_3505641874876562717gmail-m_-1237624956419455067gmail-"></span>
<div class="gmail_quote">
<div>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.<br>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>That's fair. I agree it can be made more explicit and
that it be good to do so. <span class="m_3505641874876562717gmail-m_-1237624956419455067gmail-"><br>
<br>
</span></div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>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.<br>
<br>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>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. <br>
<br>
I can look at adding some examples, if there's some
consensus that they'd be useful and this document moves
forward. <br>
</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote"><span class="m_3505641874876562717gmail-m_-1237624956419455067gmail-">
<div><br>
</div>
</span>
<div>I´m not saying it is a bad Idea just that I
would prefer if it was not a MUST. <br>
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.<br>
</div>
<div>
<div class="m_3505641874876562717gmail-m_-1237624956419455067gmail-h5">
<div><br>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>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. <br>
</div>
<div><br>
</div>
</div>
</div>
</div>
<br>
<fieldset class="m_3505641874876562717gmail-m_-1237624956419455067mimeAttachmentHeader"></fieldset>
<br>
</div></div><span class="m_3505641874876562717gmail-"><pre>______________________________<wbr>_________________
OAuth mailing list
<a class="m_3505641874876562717gmail-m_-1237624956419455067moz-txt-link-abbreviated" href="mailto:OAuth@ietf.org" target="_blank">OAuth@ietf.org</a>
<a class="m_3505641874876562717gmail-m_-1237624956419455067moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/oauth" target="_blank">https://www.ietf.org/mailman/l<wbr>istinfo/oauth</a>
</pre>
</span></blockquote>
<br>
</div>
</blockquote></div><br></div></div>
</blockquote></div></div>