<html>

<head>

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

</head>

<body>

openid/sharedsignals event <br>

<br>

Issue opened <br>

Issue Title: Initial security audit feedback <br>

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

<br>

The first draft of the security audit highlighted several small items that ought to be fixed before we move to a release version. [2024-04-09_WP4.1a-Report.pdf](https://github.com/openid/sharedsignals/files/15309694/2024-04-09_WP4.1a-Report.pdf) The relevant

 sections have been copied below. # 3. Notes on the SSF Specification Based on our work with the SSF specification, we suggest the working group consider the following changes. Most of these are based on (necessary) assumptions explained in Section 2 and we

 note that our model reflects the specification with these changes. ## Issuer Identifier Validation. While the configuration discovery specification mandates Transmitters to only use issuer identifiers with the https scheme [10, Section 6.1], there is no requirement

 for Receivers to only request configuration documents from https URLs. If a Receiver requests a Transmitter’s configuration document from an http URL, a network attacker may launch an MitM attack, resulting in the Receiver accepting arbitrary, attacker-chosen

 configuration data (including JWKs) and arbitrary, attacker-chosen SETs. We, therefore, recommend explicitly mandating Receivers to (1) obtain Transmitters’ issuer identifiers from trusted sources, and (2) verify that these issuer identifiers use the https

 scheme. In our model, we assume that these recommendations are implemented (see Section 2.5). ## Stream Configuration Management API Endpoints. The current SSF specification does not mandate the use of https for any of the stream configuration management API

 endpoints. We note that for SET delivery, [RFC8935, RFC8936] mandate the use of https URLs, and of course recommend mandating Transmitters to use https URLs for all stream management API endpoints and the JWKs endpoint. In our model, we assume that this recommendation

 is implemented (see Section 2.5). ## Requirements on Additional SET Delivery Methods. In our model, we only consider the push and poll delivery methods as defined in [RFC8935, RFC8936] (see Section 2.2). This implies that in our model, SET delivery always

 takes place via TLS-protected connections. However, the SSF 5 specification does not limit allowed delivery methods to these two. Hence, we recommend requiring the use of SET delivery methods that ensure SET confidentiality and integrity.

</body>

</html>