<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">

</head>

<body>

openid/sharedsignals event <br>

<br>

Issue Comment created on issue 140 <br>

Issue Title: Allow Receiver to supply public key <br>

https://github.com/openid/sharedsignals/issues/140 <br>

<br>

Comment: > @TakahikoKawasaki That is a great way to solve this problem! We could add an optional, receiver-supplied field to the StreamConfiguration (to be set by the receiver on stream creation or stream update) that holds the JSON object you described above.

 I like this solution better because it is a lower burden on the Receiver, especially a poll-based Receiver who might not be hosting _any_ endpoints. > > @appsdesh I am imagining that the Transmitter would encrypt the entire SET. That is, instead of just signing

 the JWT (making it a JWS) the Transmitter would encrypt and sign the JWT (making it a JWE). Do you think there would be problems with that approach? Some of the PII is potentially in the top level of the SET (i.e. the `sub_id` claim) so I think we need to

 encrypt more than just the `events`. Regarding granularity, I could foresee a scenario where encryption is particularly desired for certain subjects within a stream, and that certain subjects may even have their own associated public keys.

</body>

</html>