[Openid-specs-risc] openid/sharedsignals: New Issue opened

[github at oidf.org]

openid/sharedsignals event

Issue opened
Issue Title: Clarifying the authentication & authorization of Receiver endpoints
https://github.com/openid/sharedsignals/issues/258

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20250514/7ba8a4d1/attachment.htm>