sharedsignals
sharedsignals copied to clipboard
OpenID Shared Signals Working Group Repository
This issue is part of the ongoing formal security analysis of the SSF specification. We already created a formal model of the specification, identified and formalized security properties, and described...
The SSF specification does not require authentication of Receivers at Transmitters. Under certain conditions, this enables an attacker to get a SET for audience values of other Receivers. Please note...
Under certain conditions, an attacker might receive SETs for subjects without being authorized to access information on these subjects. We give the details in the following. Please note that this...
We have defined the use of OAuth 2.0 as an authorization scheme in our interoperability draft. This PR adds more details about using OAuth constructs to make vendor interoperability more...
We've long discussed the challenges with the event specs, which are effectively just dictionaries, being formal specifications that go through full OIDF process. This can make it challenging to add...
The `txn` claim is called out as optional on RFC 8417 but is not referenced on CAEP / RISC Events or in the general SSF documentation. With the new CAEP...
A recent comment by Phil Hunt a few days ago in PR #82 > The format value is an IANA registered format to avoid conflicts. The term "complex" is probably...
Below is the current example of update stream status response (Figure 34) in the SSF specification. ``` HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store { "stream_id": "f67e39a0a4d34d56b3aa1bc4cff0069f", "status": "paused", }...
Removed the transmitter supplied fields from the stream config PUT and PATCH examples.