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

Fix Indefinite Articles Before "SSF" #145

Merged
merged 1 commit into from
Mar 20, 2024
Merged

Fix Indefinite Articles Before "SSF" #145

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
22 changes: 11 additions & 11 deletions openid-sharedsignals-framework-1_0.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -238,7 +238,7 @@ This Shared Signals Framework specification defines a Subject Principal to be
the entities about which an event can be sent by Transmitters and received by
Receivers using the Shared Signals Framework.

Subject Principals are the managed entities in a SSF Transmitter or Receiver.
Subject Principals are the managed entities in an SSF Transmitter or Receiver.
These include human or robotic principals, devices, customer tenants in a
multi-tenanted service, organizational units within a tenant, groups of subject
principals, or other entities that are managed by Transmitters and Receivers.
Expand All @@ -251,7 +251,7 @@ Subject Principals are identified by Subject Members defined below.
# Subject Members in SSF Events {#subject-ids}

## Subject Members {#subject-members}
A Subject Member of a SSF event describes a subject of the event. A top-level claim named `sub_id` MUST be used to describe the primary subject of the event.
A Subject Member of an SSF event describes a subject of the event. A top-level claim named `sub_id` MUST be used to describe the primary subject of the event.

### Existing CAEP and RISC Events
Event types already defined in the CAEP ({{CAEP}}) and RISC ({{RISC}}) specifications MAY use a `subject` field within the `events` claim of the SSF event to describe the primary Subject Principal of the event. SSF Transmitters MUST include the top-level `sub_id` claim even for these existing event types.
Expand All @@ -269,7 +269,7 @@ Each Subject Member MUST refer to exactly one Subject Principal. The value of a

A Simple Subject Member has a claim name and a value that is a "Subject
Identifier" as defined in the Subject Identifiers for Security Event Tokens
{{SUBIDS}}. Below is a non-normative example of a Simple Subject Member in a SSF
{{SUBIDS}}. Below is a non-normative example of a Simple Subject Member in an SSF
event.

~~~ json
Expand Down Expand Up @@ -318,7 +318,7 @@ group
Additional Subject Member names MAY be used in Complex Subjects. Each member name MAY
appear at most once in the Complex Subject value.

Below is a non-normative example of a Complex Subject claim in a SSF event.
Below is a non-normative example of a Complex Subject claim in an SSF event.

~~~ json
"sub_id": {
Expand All @@ -344,7 +344,7 @@ Subject Principal.

## Subject Identifiers in SSF Events {#subject-ids-in-ssf}

A Subject Identifier in a SSF event MUST have an identifier format that is any
A Subject Identifier in an SSF event MUST have an identifier format that is any
one of:

* Defined in the IANA Registry defined in Subject Identifiers for Security
Expand Down Expand Up @@ -463,7 +463,7 @@ The following are hypothetical examples of SETs that conform to the Shared Signa
}
}
~~~
{: #subject-ids-ex-simple title="Example: SET Containing a SSF Event with a Simple Subject Member"}
{: #subject-ids-ex-simple title="Example: SET Containing an SSF Event with a Simple Subject Member"}

~~~ json
{
Expand Down Expand Up @@ -507,7 +507,7 @@ The following are hypothetical examples of SETs that conform to the Shared Signa
}
}
~~~
{: #subject-ids-ex-complex title="Example: SET Containing a SSF Event with a Complex Subject Member"}
{: #subject-ids-ex-complex title="Example: SET Containing an SSF Event with a Complex Subject Member"}

~~~ json
{
Expand All @@ -533,7 +533,7 @@ The following are hypothetical examples of SETs that conform to the Shared Signa
}
}
~~~
{: #subject-properties-ex title="Example: SET Containing a SSF Event with a Simple Subject and a Property Member"}
{: #subject-properties-ex title="Example: SET Containing an SSF Event with a Simple Subject and a Property Member"}

~~~ json
{
Expand All @@ -559,7 +559,7 @@ The following are hypothetical examples of SETs that conform to the Shared Signa
}
}
~~~
{: #subject-custom-type-ex title="Example: SET Containing a SSF Event with a Proprietary Subject Identifier Format"}
{: #subject-custom-type-ex title="Example: SET Containing an SSF Event with a Proprietary Subject Identifier Format"}

# Transmitter Configuration Discovery {#discovery}

Expand Down Expand Up @@ -1819,7 +1819,7 @@ A Transmitter MAY respond to verification event requests even if the event is no


#### Verification Event {#verification-event}
The Verification Event is a SSF Event with the event type: "https://schemas.openid.net/secevent/ssf/event-type/verification". The event contains the following attribute:
The Verification Event is an SSF Event with the event type: "https://schemas.openid.net/secevent/ssf/event-type/verification". The event contains the following attribute:

state

Expand Down Expand Up @@ -2096,7 +2096,7 @@ The signature key can be obtained through "jwks_uri", see {{discovery}}.

### SSF Event Subject {#event-subjects}
The primary Subject Member of SSF events is described in the "Subject Members" section ({{subject-ids}}). The JWT "sub" claim MUST NOT be present in any SET containing
a SSF event.
an SSF event.

### SSF Event Properties {#event-properties}
The SSF event MAY contain additional claims within the event payload that are
Expand Down
Loading