Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add SHOULD language about checking the issuer value #172

Merged
merged 2 commits into from
Jun 10, 2024
Merged

Add SHOULD language about checking the issuer value #172

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
938645e
Add SHOULD language about checking the issuer value
FragLegs May 23, 2024
d03a476
Make SHOULD and MUST and insist that the Receiver validate the iss on…
FragLegs Jun 6, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 16 additions & 3 deletions openid-sharedsignals-framework-1_0.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -927,7 +927,9 @@ In order to communicate events from a Transmitter to a Receiver, a Receiver
MUST first create an Event Stream. An Event Receiver creates a stream by making
an HTTP POST request to the Configuration Endpoint. On receiving a valid request
the Event Transmitter responds with a "201 Created" response containing a
[JSON][RFC7159] representation of the stream’s configuration in the body.
[JSON][RFC7159] representation of the stream’s configuration in the body. The Receiver
MUST check the response and confirm that the `iss` value matches the Issuer from
which it received the Transmitter Configuration data.

If a stream already exists, and the Transmitter allows multiple streams with the
same Receiver, the Event Transmitter MUST respond with a new stream ID. If the
Expand Down Expand Up @@ -1022,7 +1024,9 @@ Errors are signaled with HTTP status codes as follows:
An Event Receiver gets the current configuration of a stream by making an HTTP
GET request to the Configuration Endpoint. On receiving a valid request, the
Event Transmitter responds with a "200 OK" response containing a [JSON][RFC7159]
representation of the stream’s configuration in the body.
representation of the stream’s configuration in the body. The Receiver
MUST check the response and confirm that the `iss` value matches the Issuer from
which it received the Transmitter Configuration data.

The GET request MAY include the "stream_id" as a query parameter in order to
identify the correct Event Stream. If the "stream_id" parameter is missing,
Expand Down Expand Up @@ -1219,7 +1223,8 @@ HTTP PATCH request to the Configuration Endpoint. The PATCH body contains a
[JSON][RFC7159] representation of the stream configuration properties to change. On
receiving a valid request, the Event Transmitter responds with a "200 OK"
response containing a [JSON][RFC7159] representation of the entire updated stream
configuration in the body.
configuration in the body. The Receiver MUST check the response and confirm that the
`iss` value matches the Issuer from which it received the Transmitter Configuration data.

The stream_id property MUST be present in the request. Other properties
MAY be present in the request. Any Receiver-Supplied property present in the
Expand Down Expand Up @@ -1307,6 +1312,8 @@ HTTP PUT request to the Configuration Endpoint. The PUT body contains a JSON
{{RFC7159}} representation of the new configuration. On receiving a valid
request, the Event Transmitter responds with a "200 OK" response containing a
JSON {{RFC7159}} representation of the updated stream configuration in the body.
The Receiver MUST check the response and confirm that the `iss` value matches the
Issuer from which it received the Transmitter Configuration data.

The stream_id and the full set of Receiver-Supplied properties MUST be present
in the PUT body, not only those specifically intended to be changed.
Expand Down Expand Up @@ -2128,6 +2135,12 @@ Sections 4.5, 4.6 and 4.7 of {{RFC8417}}. While current Id Token {{OpenID.Core}}
validators may not be using the "typ" header parameter, requiring it for SSF
SETs guarantees a distinct value for future validators.

## The "iss" Claim {#iss-claim}
The "iss" claim MUST match the "iss" value in the Stream Configuration data for the stream
that the event is sent on. Receivers MUST validate that this claim matches the "iss"
in the Stream Configuration data, as well as the Issuer from which the Receiver requested
the Transmitter Configuration data.

### The "exp" Claim {#exp-claim}
The "exp" claim MUST NOT be used in SSF SETs.

Expand Down
Loading