<html>

<head>

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

</head>

<body>

openid/sharedsignals event <br>

<br>

Issue opened <br>

Issue Title: Clarifying the authentication & authorization of Receiver endpoints <br>

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

<br>

In the [Transmitter section](https://openid.net/specs/openid-sharedsignals-framework-1_0-ID3.html#name-authorization-scheme) we have > SSF is an HTTP based signals sharing framework and is agnostic to the authentication and authorization schemes used to secure

 stream configuration APIs. Note that it explicitly says "stream configuration APIs", which raises the question of the statement's applicability to other endpoints that are not related to stream configuration. - Does it apply to the Transmitter's POLL endpoint?

 - How about the Receiver's PUSH endpoint? - For PUSH delivery we support [`authorization_header`](https://openid.net/specs/openid-sharedsignals-framework-1_0-ID3.html#section-10.3.1.1-6), does that means Receivers are not expected to put this endpoint behind

 OAuth or other custom Auth? - Related: We should probably clarify the format of `authorization_header` - does it expect the value `Authorization: XYZ`, or just `XYZ` and the Transmitter will convert that to the full header. In the [PUSH RFC8935](https://www.rfc-editor.org/rfc/rfc8935.html#name-authentication-and-authoriz),

 it says > The SET delivery method described in this specification is based upon HTTP over TLS [[RFC2818](https://www.rfc-editor.org/rfc/rfc8935.html#RFC2818)] and standard HTTP authentication and authorization schemes, as per [[RFC7235](https://www.rfc-editor.org/rfc/rfc8935.html#RFC7235)].

 Does this mean that headers like `X-goog-api-key: API_KEY` are unsupported?

</body>

</html>