sharedsignals
sharedsignals copied to clipboard
openid
OpenID Shared Signals Working Group Repository
While on the Conformance Test Suite conference call, it became clear that there is some confusion around the origin of where the receivers `aud` value comes from. While the spec...
There is no default status specified and the "status" field is not present in the stream creation request for the receiver to specify.
Copying discussion from meeting on 9/24: - [Tushar] the spec implicitly assumes that a stream is permanent once created. Should it support expirable streams? - [Tushar] Possible solution: verification events...
Use SSF 1.0, CAEP 1.0, RFC9728, FAPI 2.0 Security Profile Fixes #291
Starting a discussion to focus specifically on simplifying the auth story of Receivers calling Transmitter endpoints. I believe an equivalent story for Receivers, as we have for Transmitters (sending signed...
We have well-defined configuration metadata for transmitters : https://openid.net/specs/openid-sharedsignals-framework-1_0.html#name-obtaining-transmitter-confi But nothing equivalent exist for receivers. There are few usecases for this : 1. Non-existence of such config somewhat forces integration...
_Subject identity_ is a core part of SSF events - most events talk about something that happened to/with/by/etc. a subject. But given the nature of Transmitters and Receivers as distinct...
As discussed in todays SSF WG call, we need to document some required features and expected behaviours from SSF Recievers to implement proper conformance tests.
Update the latest version of the [CAEP Interoperability Profile 1.0 - draft 01](https://openid.github.io/sharedsignals/openid-caep-interoperability-profile-1_0.html) with references to the final specifications. - [Shared Signals Framework 1.0 Final](https://openid.net/specs/openid-sharedsignals-framework-1_0-final.html#section-7.1.4.1) - [FAPI 2.0 Security Profile](https://openid.net/specs/fapi-security-profile-2_0-final.html)...