<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;" 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><blockquote type="cite" class=""><div class="">On Aug 28, 2015, at 2:09 PM, Luiz Omori &lt;luiz.omori@duke.edu&gt; wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" 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="defaultsignerService" class="org.mitre.jwt.signer.service.impl.DefaultJWTSigningAndValidationService"&gt;</div>
<div class=""><span class="Apple-tab-span" style="white-space:pre"></span>&lt;constructor-arg name="keyStore" ref="defaultKeyStore" /&gt;</div>
<div class=""><span class="Apple-tab-span" style="white-space:pre"></span>&lt;property name="defaultSignerKeyId" value="rsa1" /&gt;</div>
<div class="">&nbsp;<span class="Apple-tab-span" style="white-space:pre"> </span>&lt;property name="defaultSigningAlgorithmName" value="RS256" /&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;">"jwks_uri"</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;">"http://localhost:8080/ldap-openid-connect-server/jwk”</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="">mitreid-connect@mit.edu<br class="">http://mailman.mit.edu/mailman/listinfo/mitreid-connect<br class=""></div></blockquote></div><br class=""></div></div></div></div></body></html>