<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Thanks Tom for the reminder!</p>
<p>The issuer is the OIDC RP.</p>
<p>Vladimir<br>
</p>
<div class="moz-cite-prefix">On 08/06/2020 17:29, Tom Jones via
Openid-specs-ab wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAK2Cwb5p9fkzxkchHqNvo_fohS89DSLD-L4hfg8zX2Say72kSw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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"
moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">Openid-specs-ab@lists.openid.net</a><br>
<a
href="http://lists.openid.net/mailman/listinfo/openid-specs-ab"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>