Allow Receiver to supply public key

In the current SSF spec, the Transmitter can make a jwks.json file available to its Receivers. This allows the Transmitter to sign the JWTs that it is sending the Receiver, so that the Receiver can verify that the security event tokens (SETs) are not forged by some third party. However, these security event tokens often contain personally identifying information (PII) and some vendors may wish to be able to encrypt the SET, not just sign it. In order to do that, the Transmitter would need the Receiver to share a public key. I propose that we add language to the spec to make it clear that a Receiver MAY provide well-known and jwks.json endpoints for this purpose.

The current spec treats Receivers as an afterthought - all of the language is around what Transmitters MAY and MUST do. This would give us an opportunity to make Receivers more of a first class citizen in the SSF spec.

Start by reading the current SSF spec language about Transmitters, Receivers, well-known endpoints, and jwks.json. Compare the existing treatment of Transmitters with the proposed Receiver behavior; done means the spec clearly states when a Receiver MAY provide these endpoints for public-key sharing and gives Receivers a first-class role.