<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>Sorry, yes RO==RS in my email.&nbsp;</div>
<div><br>
</div>
<div>And there is the kid for the encryption too, eh?&nbsp;<a href="https://tools.ietf.org/html/rfc7516#section-4.1.6">https://tools.ietf.org/html/rfc7516#section-4.1.6</a></div>
<div><br>
</div>
<div>Introspection indeed…</div>
<div><br>
</div>
<div>Regards,</div>
<div>Luiz</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Justin Richer &lt;<a href="mailto:jricher@mit.edu">jricher@mit.edu</a>&gt;<br>
<span style="font-weight:bold">Date: </span>Friday, August 28, 2015 at 4:55 PM<br>
<span style="font-weight:bold">To: </span>Luiz Omori &lt;<a href="mailto:luiz.omori@dm.duke.edu">luiz.omori@dm.duke.edu</a>&gt;<br>
<span style="font-weight:bold">Cc: </span>&quot;<a href="mailto:mitreid-connect@mit.edu">mitreid-connect@mit.edu</a>&quot; &lt;<a href="mailto:mitreid-connect@mit.edu">mitreid-connect@mit.edu</a>&gt;<br>
<span style="font-weight:bold">Subject: </span>Re: [mitreid-connect] Keystore<br>
</div>
<div><br>
</div>
<div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
I’m assuming by “RO” here you actually mean “RS”, resource server. I’m going to answer based on that, so correct me if I’m wrong. :)
<div class=""><br class="">
</div>
<div class="">If the AS isn’t including the kid in the access token, then that’s a bug (and a simple one to fix). If that’s the case, please file an issue on GitHub and we’ll roll that into a future patch release. The ID token and access token might be signed
 with different keys (they usually aren’t in MITREid Connect, but nothing says they have to be signed with the same key in the spec).&nbsp;</div>
<div class=""><br class="">
</div>
<div class="">As the RS, you can also just do token introspection if you like, avoiding parsing the token entirely.&nbsp;</div>
<div class=""><br class="">
</div>
<div class="">&nbsp;— Justin</div>
<div class=""><br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Aug 28, 2015, at 3:34 PM, Luiz Omori &lt;<a href="mailto:luiz.omori@duke.edu" class="">luiz.omori@duke.edu</a>&gt; wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-size: 14px; font-family: Calibri, sans-serif;" class="">
<div class="">Thanks, that’s what I thought about the possibility of multiple “use”: “sig”. &nbsp;But then, here is the question: let’s say I’m the Resource Owner and I got a request which presumably only contains the access_token. Without the ID token we don’t
 know the kid? Currently we do verify the signature at the RO and we are using the well-known-&gt;jwk call to retrieve the IdP PK. If in addition to that I need to configure the name of the key on the RO side as well that would be just slightly better than storing
 the signing PK itself on the RO and save a few well-known-&gt;jwk requests.</div>
<div class=""><br class="">
</div>
<div class="">Regarding the error, what do you mean? It happened within MitreID itself. We should be using whatever MitreID is configured for and the library version is defined in the POM. Oh, we are still on 1.1.16, haven’t tried the latest.</div>
<div class=""><br class="">
</div>
<div class="">Regards,</div>
<div class="">Luiz</div>
<div class=""><br class="">
</div>
<span id="OLK_SRC_BODY_SECTION" class="">
<div style="font-family: Calibri; font-size: 11pt; text-align: left; border-width: 1pt medium medium; border-style: solid none none; padding: 3pt 0in 0in; border-top-color: rgb(181, 196, 223);" class="">
<span style="font-weight:bold" class="">From: </span>Justin Richer &lt;<a href="mailto:jricher@mit.edu" class="">jricher@mit.edu</a>&gt;<br class="">
<span style="font-weight:bold" class="">Date: </span>Friday, August 28, 2015 at 2:48 PM<br class="">
<span style="font-weight:bold" class="">To: </span>Luiz Omori &lt;<a href="mailto:luiz.omori@dm.duke.edu" class="">luiz.omori@dm.duke.edu</a>&gt;<br class="">
<span style="font-weight:bold" class="">Cc: </span>&quot;<a href="mailto:mitreid-connect@mit.edu" class="">mitreid-connect@mit.edu</a>&quot; &lt;<a href="mailto:mitreid-connect@mit.edu" class="">mitreid-connect@mit.edu</a>&gt;<br class="">
<span style="font-weight:bold" class="">Subject: </span>Re: [mitreid-connect] Keystore<br class="">
</div>
<div class=""><br class="">
</div>
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
The “kid” field is what differentiates the keys when there are multiple ones there. I suppose you *could* just look at all the keys and pick whichever one is set up for “use:sig”, but then what do you do if you’ve got multiple “use:sig” keys and you need to
 sign something? Better to use an explicit identifier, which MITREid Connect requires in its keystores for this purpose. Also, OIDC requires the use of the “kid” field in the ID token to indicate which key was used to sign the token if there are more than one
 to choose from in the JWK set:
<div class=""><br class="">
</div>
<div class=""><a href="http://openid.net/specs/openid-connect-core-1_0.html#Signing" class="">http://openid.net/specs/openid-connect-core-1_0.html#Signing</a><br class="">
<div class=""><br class="">
</div>
<div class="">We currently only support one signing key at a time (and only one encryption key for that matter), but multiple can be in the store and published. The JWK endpoint will publish all available public keys in the keystore. The public keys are generated
 by reading the public/private keypairs and stripping out the private key information, as you discovered.&nbsp;
<div class="">
<div class=""><br class="">
</div>
<div class="">The “defaultSigningAlgorithm” property does not select the key, it selects the signature algorithm applied to server-signed objects (like ID tokens) if there isn’t one specified by the client’s specific configuration.</div>
<div class=""><br class="">
</div>
<div class="">As for the error, it looks like our underlying JOSE library is perhaps too strict in its parsing, so you may want to file a bug on their end. However, none of our production systems have used the “use” field.</div>
<div class=""><br class="">
</div>
<div class="">&nbsp;— Justin</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On Aug 28, 2015, at 2:09 PM, Luiz Omori &lt;<a href="mailto:luiz.omori@duke.edu" class="">luiz.omori@duke.edu</a>&gt; wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div style="font-size: 14px; font-family: Calibri, sans-serif;" class="">Hi,</div>
<div style="font-size: 14px; font-family: Calibri, sans-serif;" class=""><br class="">
</div>
<div style="font-size: 14px; font-family: Calibri, sans-serif;" class="">One minor thing, but that surprisingly is generating quite a few emails internally, is indirectly related to the configuration below (crypto-config.xml):</div>
<div style="font-size: 14px; font-family: Calibri, sans-serif;" class=""><br class="">
</div>
<div style="font-size: 14px; font-family: Calibri, sans-serif;" class="">
<div class=""><span class="Apple-tab-span" style="white-space:pre"></span>&lt;bean id=&quot;defaultsignerService&quot; class=&quot;org.mitre.jwt.signer.service.impl.DefaultJWTSigningAndValidationService&quot;&gt;</div>
<div class=""><span class="Apple-tab-span" style="white-space:pre"></span>&lt;constructor-arg name=&quot;keyStore&quot; ref=&quot;defaultKeyStore&quot; /&gt;</div>
<div class=""><span class="Apple-tab-span" style="white-space:pre"></span>&lt;property name=&quot;defaultSignerKeyId&quot; value=&quot;rsa1&quot; /&gt;</div>
<div class="">&nbsp;<span class="Apple-tab-span" style="white-space:pre"> </span>&lt;property name=&quot;defaultSigningAlgorithmName&quot; value=&quot;RS256&quot; /&gt;</div>
<div class=""><span class="Apple-tab-span" style="white-space:pre"></span>&lt;/bean&gt;</div>
</div>
<div style="font-size: 14px; font-family: Calibri, sans-serif;" class=""><br class="">
</div>
<div style="font-size: 14px; font-family: Calibri, sans-serif;" class="">Question: can “use”: “sig” (as defined in&nbsp;<a href="https://tools.ietf.org/html/draft-ietf-jose-json-web-key-41" class="">https://tools.ietf.org/html/draft-ietf-jose-json-web-key-41</a>)
 be used as discriminator for the signing key? In other words, why use the key ID and algorithm?</div>
<div style="font-size: 14px; font-family: Calibri, sans-serif;" class=""><br class="">
</div>
<div class="">If multiple keys with “use”: “sig” may be present, how does the client know which one returned from&nbsp;<span class="sObjectK" id="s-266" style="box-sizing: border-box; font-weight: 700; color: rgb(51, 51, 51); line-height: 22.8571434020996px; widows: 1;">&quot;jwks_uri&quot;</span><span class="sColon" id="s-267" style="box-sizing: border-box; color: rgb(102, 102, 102); line-height: 22.8571434020996px; widows: 1;">:</span><span class="sObjectV" id="s-268" style="box-sizing: border-box; color: rgb(85, 85, 85); line-height: 22.8571434020996px; widows: 1;">&quot;<a href="http://localhost:8080/ldap-openid-connect-server/jwk" class="">http://localhost:8080/ldap-openid-connect-server/jwk</a>”</span>&nbsp;(from
 well-known endpoint) should be used? We’ve noticed that that endpoint seems to be returning all keys (we haven’t tested other private keys but at least for the one used for signing the private modulus is removed, as expected).&nbsp;</div>
<div style="font-size: 14px; font-family: Calibri, sans-serif;" class=""><br class="">
</div>
<div style="font-size: 14px; font-family: Calibri, sans-serif;" class="">Regards,</div>
<div style="font-size: 14px; font-family: Calibri, sans-serif;" class="">Luiz</div>
</div>
_______________________________________________<br class="">
mitreid-connect mailing list<br class="">
<a href="mailto:mitreid-connect@mit.edu" class="">mitreid-connect@mit.edu</a><br class="">
<a href="http://mailman.mit.edu/mailman/listinfo/mitreid-connect" class="">http://mailman.mit.edu/mailman/listinfo/mitreid-connect</a><br class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</div>
</div>
</div>
</div>
</span></div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</div>
</span>
</body>
</html>