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.

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

Issue 163 - add field to configuration data indicating expected subject behavior for new streams #168

Merged
merged 6 commits into from
Jun 13, 2024
Merged
Changes from all commits
Commits
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
18 changes: 16 additions & 2 deletions openid-sharedsignals-framework-1_0.md
Original file line number Diff line number Diff line change
Expand Up @@ -587,6 +587,19 @@ authorization_schemes
security considerations, make the authorization_schemes attribute
publicly accessible without prior authentication.

default_subjects

> OPTIONAL. A string indicating the default behavior of newly created streams. If present,
the value MUST be either "ALL" or "NONE". If not provided, the Transmitter behavior in
this regard is unspecified.
> - "ALL" indicates that any subjects that are appropriate for the stream are added to
the stream by default. The Receiver MAY remove subjects from the stream via the
`remove_subject_endpoint`, causing events for those subjects to _not_ be transmitted.
The Receiver MAY re-add any subjects removed this way via the `add_subject_endpoint`.
> - "NONE" indicates that no subjects are added by default. The Receiver MAY add subjects
to the stream via the `add_subject_endpoint`, causing only events for those subjects
to be transmitted. The Receiver MAY remove subjects added this way via the
`remove_subject_endpoint`.

TODO: consider adding a IANA Registry for metadata, similar to Section 7.1.1 of
{{RFC8414}}. This would allow other specs to add to the metadata.
Expand Down Expand Up @@ -719,7 +732,8 @@ Content-Type: application/json
{
"spec_urn": "urn:ietf:rfc:8705"
}
]
],
"default_subjects": "NONE"
}
~~~
{: #figdiscoveryresponse title="Example: Transmitter Configuration Response"}
Expand Down Expand Up @@ -2158,7 +2172,7 @@ multiple Receivers would lead to unintended data disclosure.
{: title="Example: SET with array 'aud' claim" #figarrayaud}

### The "txn" claim {#txn-claim}
Transmitters SHOULD set the "txn" claim value in Security Event Tokens (SETs). If the value is present, it MUST be unique to the underlying event that caused the Transmitter to generate the Security Event Token (SET). The Transmitter, however, may use the same value in the "txn" claim across different Security Events Tokens (SETs), such as session revoked and credential change, to indicate that the SETs originated from the same underlying cause or reason.
Transmitters SHOULD set the "txn" claim value in Security Event Tokens (SETs). If the value is present, it MUST be unique to the underlying event that caused the Transmitter to generate the Security Event Token (SET). The Transmitter, however, may use the same value in the "txn" claim across different Security Events Tokens (SETs), such as session revoked and credential change, to indicate that the SETs originated from the same underlying cause or reason.

### The "events" claim {#events-claim}
The "events" claim SHOULD contain only one event. Multiple event type URIs are
Expand Down
Loading