<div dir="ltr">It seems like I need to repeat this same warning at least once per year.<div><br></div><div>The issue with key retention is NOT when the issuer will need to use the keys, but how long any relying party (in the broadest possible sense) might need to use the keys. For signing keys this means when will someone need to verify a signature, for encryption keys it means when will someone need to decrypt an archived version of the data. For example, the master CA keys need to be available for 25 years after they were last used to sign a certificate.<br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Peace ..tom</div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jun 7, 2020 at 11:48 PM Vladimir Dzhuvinov via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">New issue 1174: Federation: 9.2.2.2.1. The OP Constructing the Response - Clarify which keys need to be preserved to facilitate roll-over<br>
<a href="https://bitbucket.org/openid/connect/issues/1174/federation-92221-the-op-constructing-the" rel="noreferrer" target="_blank">https://bitbucket.org/openid/connect/issues/1174/federation-92221-the-op-constructing-the</a><br>
<br>
Vladimir Dzhuvinov:<br>
<br>
In [<a href="https://openid.net/specs/openid-connect-federation-1%5C_0.html#rfc.section.9.2.2.2.1](https://openid.net/specs/openid-connect-federation-1_0.html%23rfc.section.9.2.2.2.1)" rel="noreferrer" target="_blank">https://openid.net/specs/openid-connect-federation-1\_0.html#rfc.section.9.2.2.2.1](https://openid.net/specs/openid-connect-federation-1_0.html#rfc.section.9.2.2.2.1)</a><br>
<br>
> At this point, if there already exists a client registration under the same entity identifier then that registration MUST be regarded as invalid. **Note that key material from the previous registration MUST be kept to make key rollover possible.**<br>
<br>
Is this the entity JWK set or the JWK set referenced by the client metadata \( `jwks_uri` or `jwks`\)?<br>
<br>
1. If it’s the entity statement JWK set we don’t quite understand why these will need to be kept after an update.<br>
2. As for the jwks\_uri / jwks, the roll-over is managed by the RP / client, by simply keeping the old keys in the set, until no longer used.<br>
<br>
If some roll-over needs to happen re 1 \(entity statement JWK set\) then this could also be managed by the client, thus making the requirement for the OP redundant.<br>
<br>
<br>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div>