<div dir="ltr"><div><div><div><div>I'm trying to work though the practical implications of JWK & X.509 support as a Connect OP for signatures.<br><br></div>It seems likely that 1) an OP will want to publish keys in both formats to "play nice" with a variety of clients that may only be able to handle one format or the other and 2) an OP will want to publish multiple keys to support different algorithms and facilitate key rollover.<br>

<br></div>Connect Messages §4.2 [1] says that "if keys are specified in both X.509 and JWK formats, they MUST be the same keys" and §4.3 [2]says that "if there are multiple keys in the referenced JWK document, the
            <tt>kid</tt> MUST be specified in the JWS header. 
            If there are multiple certificates at the referenced certificate location,
            then <tt>x5t</tt> MUST be specified in the JWS header."<br><br></div>Connecting the dots from my assumptions above and the requirements from Connect, it seems like it will be very common to have ID Tokens with both the kid and x5t JWS header parameters. Which makes sense on some level but I can't help the feeling that it's kind of inefficient, particularly with all the emphasis that's been put on keeping id tokens small(ish). <br>

<br></div><div>I don't have an alternative in mind but, in thinking about it, I guess I did want to ask a few questions:<br><br></div><div>Are my assumptions valid?<br></div><div>If so, is the end result really what Connect intended?<br>

</div><div>Or am I confused or way off base here?<br></div><div><br></div><div>Thanks in advance for any insights, thoughts or corrections,<br></div><div>Brian<br></div><div><br><div>[1] <a href="http://openid.net/specs/openid-connect-messages-1_0-13.html#sigenc.key">http://openid.net/specs/openid-connect-messages-1_0-13.html#sigenc.key</a><br>

[2] <a href="http://openid.net/specs/openid-connect-messages-1_0-13.html#sigs">http://openid.net/specs/openid-connect-messages-1_0-13.html#sigs</a><br></div></div></div>