From 971840a33676d2681402de951ff8d698ce5b2ee1 Mon Sep 17 00:00:00 2001 From: "Jonathan Thorpe (Sony)" Date: Wed, 13 Nov 2024 09:09:09 +0000 Subject: [PATCH 1/2] Tweak language --- docs/Behaviour - Resource Servers.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/Behaviour - Resource Servers.md b/docs/Behaviour - Resource Servers.md index 51416dc..fe07fc2 100644 --- a/docs/Behaviour - Resource Servers.md +++ b/docs/Behaviour - Resource Servers.md @@ -22,7 +22,8 @@ Resource Servers SHOULD attempt to verify tokens against all keys presented at t endpoint. All valid JWK's SHOULD be tried until the token is verified or until no keys are left. Where a Resource Server has no matching public key for a given token, it SHOULD attempt to obtain the missing public key -via the the token `iss` claim as specified in [RFC 8414][RFC-8414] section 3. In cases where the Resource Server needs +from the Authorization Server's "jwks_uri" property, which is found in the server metadata. The server metadata can be obtained +from a URI based on the token's issuer (`iss`) claim as specified in [RFC 8414][RFC-8414] section 3. In cases where the Resource Server needs to fetch a public key from a remote Authorization Server it MAY temporarily respond with an HTTP 503 code in order to avoid blocking the incoming authorized request. When a HTTP 503 code is used, the Resource Server SHOULD include an HTTP `Retry-After` header to indicate when the client may retry its request. From a658eb6990062976d7a57d4fb438c63fee823fb4 Mon Sep 17 00:00:00 2001 From: "Jonathan Thorpe (Sony)" Date: Wed, 4 Dec 2024 09:40:49 +0000 Subject: [PATCH 2/2] Remove spurious apostrophe. --- docs/Behaviour - Resource Servers.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/Behaviour - Resource Servers.md b/docs/Behaviour - Resource Servers.md index fe07fc2..06f1787 100644 --- a/docs/Behaviour - Resource Servers.md +++ b/docs/Behaviour - Resource Servers.md @@ -19,7 +19,7 @@ If a Resource Server is unable to contact an Authorization Server, the Resource public keys remain valid until it is able to re-establish a connection to an Authorization Server. Resource Servers SHOULD attempt to verify tokens against all keys presented at the Authorization Server's public key -endpoint. All valid JWK's SHOULD be tried until the token is verified or until no keys are left. +endpoint. All valid JWKs SHOULD be tried until the token is verified or until no keys are left. Where a Resource Server has no matching public key for a given token, it SHOULD attempt to obtain the missing public key from the Authorization Server's "jwks_uri" property, which is found in the server metadata. The server metadata can be obtained