[Federation] trivial editorial issues

Section 1.1

<xref target="RFC2119">RFC 2119</xref> → <xref target="RFC2119"/>

‌

Section 3.1, sub

Add a period at the end of the paragraph.

‌

Section 3.1, iat

<xref target="RFC3339">RFC 3339</xref> → <xref target="RFC3339"/>

‌

Section 3.1, jwks

Key ID (kid) → Key ID (<spanx style=”verb”>kid</spanx>)

‌

Section 4.2, request_authentication_methods_supported

Therefor → Therefore

‌

Section 4.2, signed_jwks_uri

included in the JWK that → included in the JWK Set that

‌

Section 4.2, jwks

unable to use the signed_jwks_uri parameter → unable to use the <spanx style=”verb”>signed_jwks_uri</spanx> parameter
One significant downside of jwks is that it does not enable key rotation (which signed_jwks_uri and jwks_uri does). → One significant downside of <spanx style=”verb”>jwks</spanx> is that it does not enable key rotation (which <spanx style=”verb”>signed_jwks_uri</spanx> and <spanx style=”verb”>jwks_uri</spanx> do).

‌

Section 4.2, OP’s entity statement

signed_jwks.json → signed_jwks.jose

‌

Section 5.1.1, superset_of

We define superset the mathematical way → We define superset in a mathematical way

‌

Section 5.1.1, the last paragraph

subset_of, superset_of and defaults are still expressed → <spanx style=”verb”>subset_of</spanx>, <spanx style=”verb”>superset_of</spanx> and <spanx style=”verb”>default</spanx> are still expressed

‌

Section 5.1.4, the third bullet

If the parameter still has no value apply the default if there is one. → If the parameter still has no value, apply the default if there is one. (insert a comma between “value” and “apply”)

‌

Section 5.1.4, the fourth bullet

If essential is missing as an operator essential is to be treated → If essential is missing as an operator, essential is to be treated (insert a comma between “operator” and “essential”)

‌

Section 5.1.4, the fifth bullet

Verified that → Verify that

‌

Section 5.1.5, the first paragraph

OAUth2 → OAuth2

‌

Section 5.3.3, example of a trust mark claim inside an entity statemenT

Entries in openid_relying_party are not properly indented.

‌

Section 6.1

request to the Entity https://example.com → request to the Entity https://openid.sunet.se

‌

Section 7.1.1, iss

which issuer we want entity statements from → which issuer you want entity statements from

‌

Section 7.2.2, the first paragraph

The response MAY also contains → The response MAY also contain

‌

Section 7.3.1, the first paragraph

https scheme to a ~~resolve~~ list endpoint. → https scheme to a list endpoint.

‌

Section 7.3.1, the second paragraph

an API request for trust negotiation → an API request for a list of entities

‌

Section 7.4.1, the first paragraph

https scheme to a ~~resolved~~ status endpoint → https scheme to a status endpoint
with the following query ~~string~~ parameters → with the following query parameters

‌

Section 7.4.1, sub

The entity_id for the entity to which → The ID of the entity to which

‌

Section 7.4.1, iat

by sub. ~~Then~~ the last ~~last~~ one → by sub, the last one

‌

Section 7.4.1, trust_mark

Add a period at the end of the paragraph.

‌

Section 8, the first paragraph

with a remote peer, MUST have → with a remote peer MUST have (remove the comma)

‌

Section 8.2, the third last paragraph

a much more expensive operation then → a much more expensive operation than
An implementer MAY therefore chose to not verify → An implementer MAY therefore choose to not verify

‌

Section 8.4

expiration time (exp) → expiration time (<spanx style=”verb”>exp</spanx>)
minimum value of exp → minimum value of <spanx style=”verb”>exp</spanx>

‌

Section 9.1

updated version of the public key. → updated version of the public keys.

‌

Section 10.2.1.1, the third bullet

influenced by the OPs metadata → influenced by the OP's metadata

‌

Section 11.1.1, client_registration_types_supported, metadata description

Federation Types Supported → Client Registration Types Supported

‌

Section 11.2.1, client_registration_type, metadata description

Federation Type → Client Registration Type

‌

A.1, the second last paragraph

a one-layer federation like Internet2 → a one-layer federation like InCommon

‌

A.3.1, authorization request

GET /authorize? → GET /openid/authorization?

‌

A.3.2

https://wiki.ligo.org/callback → https://wiki.ligo.org/openid/callback (modify redirect_uris in the examples in A.3.2, or modify redirect_uri and the content of request of the authorization request in A.3.1)
metadata_policy/openid_relying_party should include redirect_uris because OIDC servers reject authentication requests including an unregistered redirect_uri unless PAR is used. (cf. RFC 9126 Section 2.4)

‌

Section 1.1

Section 3.1, sub

Section 3.1, iat

Section 3.1, jwks

Section 4.2, request_authentication_methods_supported

Section 4.2, signed_jwks_uri

Section 4.2, jwks

Section 4.2, OP’s entity statement

Section 5.1.1, superset_of

Section 5.1.1, the last paragraph

Section 5.1.4, the third bullet

Section 5.1.4, the fourth bullet

Section 5.1.4, the fifth bullet

Section 5.1.5, the first paragraph

Section 5.3.3, example of a trust mark claim inside an entity statemenT

Section 6.1

Section 7.1.1, iss

Section 7.2.2, the first paragraph

Section 7.3.1, the first paragraph

Section 7.3.1, the second paragraph

Section 7.4.1, the first paragraph

Section 7.4.1, sub

Section 7.4.1, iat

Section 7.4.1, trust_mark

Section 8, the first paragraph

Section 8.2, the third last paragraph

Section 8.4

Section 9.1

Section 10.2.1.1, the third bullet

Section 11.1.1, client_registration_types_supported, metadata description

Section 11.2.1, client_registration_type, metadata description

A.1, the second last paragraph

A.3.1, authorization request

A.3.2

Comments (8)