From 2d67a84b8d1bf3eb2df869a40e32f0e5f0ab215d Mon Sep 17 00:00:00 2001 From: Jesse Wright <63333554+jeswr@users.noreply.github.com> Date: Sun, 15 Feb 2026 20:00:42 +0000 Subject: [PATCH 01/11] feat: add client credentials as a MUST --- index.bs | 35 +++++++++++++++++++++++++++++++---- 1 file changed, 31 insertions(+), 4 deletions(-) diff --git a/index.bs b/index.bs index 7f2f647..f2ef1a1 100644 --- a/index.bs +++ b/index.bs @@ -113,7 +113,11 @@ from a browser or an application. Therefore, this specification assumes the use of the [Authorization Code Flow](https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowSteps) with -PKCE, in accordance with OAuth and OIDC best practices. It is also assumed that there are no +PKCE, in accordance with OAuth and OIDC best practices, for interactive browser-based login. +For non-interactive use cases such as scripts, automated agents, and server-to-server communication, +this specification also requires support for the +[Client Credentials Grant](https://www.rfc-editor.org/rfc/rfc6749#section-4.4). +It is also assumed that there are no preexisting trust relationships with the OP. This means that client registration, whether dynamic, or static, is entirely optional. @@ -288,13 +292,31 @@ Solid-OIDC defines the following `scope` value for use with claim requests: REQUIRED. This scope requests access to the End-User's `webid` Claim. +# Client Credentials Grant # {#client-credentials} + +OpenID Providers MUST support the OAuth 2.0 Client Credentials Grant [[!RFC6749]] (Section 4.4) +to enable non-interactive authentication for scripts, automated agents, and server-to-server +communication. + +When using the Client Credentials Grant, the Client authenticates with the OP using a +`client_id` and `client_secret` pair previously obtained through client registration +(either static or dynamic). The Client sends a token request to the OP's token endpoint +with `grant_type=client_credentials` and the `webid` scope. + +The OP MUST validate the `client_id` and `client_secret`, and if valid, MUST return +a DPoP-bound Access Token. The Client MUST include a valid DPoP proof [[!DPOP]] +with the token request. + +The OP MUST advertise `client_credentials` in its `grant_types_supported` +metadata property in its OpenID Connect Discovery 1.0 [[!OIDC-DISCOVERY]] document. + # Token Instantiation # {#tokens} Assuming one of the following options - - Client ID and Secret, and valid DPoP Proof (for dynamic and static registration) + - Client ID and Secret, and valid DPoP Proof, using either the Authorization Code Grant or the Client Credentials Grant - Dereferencable Client Identifier with a proper Client ID Document and valid DPoP Proof (for a Solid client identifier) -the OP MUST return A DPoP-bound OIDC ID Token. +the OP MUST return a DPoP-bound OIDC ID Token. ## DPoP-bound OIDC ID Token ## {#tokens-id} @@ -401,10 +423,15 @@ requested resource. An OpenID Provider that conforms to the Solid-OIDC specification MUST advertise it in the OpenID Connect Discovery 1.0 [[!OIDC-DISCOVERY]] resource by including `webid` in its `scopes_supported` metadata property. +Additionally, the OP MUST include `client_credentials` in its `grant_types_supported` +metadata property to indicate support for non-interactive authentication +via the Client Credentials Grant (see [[#client-credentials]]). + 
         {
-            "scopes_supported": ["openid", "offline_access", "webid"]
+            "scopes_supported": ["openid", "offline_access", "webid"],
+            "grant_types_supported": ["authorization_code", "refresh_token", "client_credentials"]
         }
From f2fb70577f2c31571d350e08e82dfd173afa4f02 Mon Sep 17 00:00:00 2001 From: Jesse Wright <63333554+jeswr@users.noreply.github.com> Date: Tue, 17 Feb 2026 18:04:46 +0000 Subject: [PATCH 02/11] fix: Use `Access` token rather than `OIDC ID` token Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> --- index.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.bs b/index.bs index f2ef1a1..ee89127 100644 --- a/index.bs +++ b/index.bs @@ -304,7 +304,7 @@ When using the Client Credentials Grant, the Client authenticates with the OP us with `grant_type=client_credentials` and the `webid` scope. The OP MUST validate the `client_id` and `client_secret`, and if valid, MUST return -a DPoP-bound Access Token. The Client MUST include a valid DPoP proof [[!DPOP]] +a DPoP-bound OIDC ID Token. The Client MUST include a valid DPoP proof [[!DPOP]] with the token request. The OP MUST advertise `client_credentials` in its `grant_types_supported` From 6a5e05b18f7ab68191a84c7087bbf5bc77c3b834 Mon Sep 17 00:00:00 2001 From: Jesse Wright <63333554+jeswr@users.noreply.github.com> Date: Tue, 17 Feb 2026 18:08:31 +0000 Subject: [PATCH 03/11] fix: Refer to `Authorization Server` over `OpenID Providers` --- index.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.bs b/index.bs index ee89127..c313853 100644 --- a/index.bs +++ b/index.bs @@ -294,7 +294,7 @@ Solid-OIDC defines the following `scope` value for use with claim requests: # Client Credentials Grant # {#client-credentials} -OpenID Providers MUST support the OAuth 2.0 Client Credentials Grant [[!RFC6749]] (Section 4.4) +Authorization Servers MUST support the OAuth 2.0 Client Credentials Grant [[!RFC6749]] (Section 4.4) to enable non-interactive authentication for scripts, automated agents, and server-to-server communication. From 840ccef6d98bc1eaf38ecf0cc7e606f156f80ec9 Mon Sep 17 00:00:00 2001 From: Samu Lang Date: Fri, 6 Mar 2026 11:09:03 +0000 Subject: [PATCH 04/11] Extract changes to separate section --- index.bs | 73 +++++++++++++++++++++++++++++++------------------------- 1 file changed, 41 insertions(+), 32 deletions(-) diff --git a/index.bs b/index.bs index 3622c40..47b9e18 100644 --- a/index.bs +++ b/index.bs @@ -114,11 +114,7 @@ from a browser or an application. Therefore, this specification assumes the use of the [Authorization Code Flow](https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowSteps) with -PKCE, in accordance with OAuth and OIDC best practices, for interactive browser-based login. -For non-interactive use cases such as scripts, automated agents, and server-to-server communication, -this specification also requires support for the -[Client Credentials Grant](https://www.rfc-editor.org/rfc/rfc6749#section-4.4). -It is also assumed that there are no +PKCE, in accordance with OAuth and OIDC best practices. It is also assumed that there are no preexisting trust relationships with the OP. This means that client registration, whether dynamic, or static, is entirely optional. @@ -296,9 +292,9 @@ Solid-OIDC defines the following `scope` value for use with claim requests: # Issuer Validation after receiving the Authorization Code # {#iss-check} -In accordance with Best Current Practice [[RFC9700]], -defense against [Mix-Up Attacks](https://www.rfc-editor.org/rfc/rfc9700.html#section-4.4) -is required in Solid-OIDC as clients are expected to interact with more than one OP. +In accordance with Best Current Practice [[RFC9700]], +defense against [Mix-Up Attacks](https://www.rfc-editor.org/rfc/rfc9700.html#section-4.4) +is required in Solid-OIDC as clients are expected to interact with more than one OP. To this end, this specification adopts the mechanism defined in [[!RFC9207]]. The OP MUST include the `iss` query parameter alongside the authorization code when redirecting the user agent back to the Client's redirect_uri. @@ -321,31 +317,13 @@ Upon receiving the authorization response, the Client MUST validate the `iss` pa If the `iss` parameter is missing or does not match the expected value, the Client MUST reject the response, MUST NOT exchange the authorization code for tokens, and SHOULD signal an error to the user. -# Client Credentials Grant # {#client-credentials} - -Authorization Servers MUST support the OAuth 2.0 Client Credentials Grant [[!RFC6749]] (Section 4.4) -to enable non-interactive authentication for scripts, automated agents, and server-to-server -communication. - -When using the Client Credentials Grant, the Client authenticates with the OP using a -`client_id` and `client_secret` pair previously obtained through client registration -(either static or dynamic). The Client sends a token request to the OP's token endpoint -with `grant_type=client_credentials` and the `webid` scope. - -The OP MUST validate the `client_id` and `client_secret`, and if valid, MUST return -a DPoP-bound OIDC ID Token. The Client MUST include a valid DPoP proof [[!DPOP]] -with the token request. - -The OP MUST advertise `client_credentials` in its `grant_types_supported` -metadata property in its OpenID Connect Discovery 1.0 [[!OIDC-DISCOVERY]] document. - # Token Instantiation # {#tokens} Assuming one of the following options - - Client ID and Secret, and valid DPoP Proof, using either the Authorization Code Grant or the Client Credentials Grant + - Client ID and Secret, and valid DPoP Proof (for dynamic and static registration) - Dereferencable Client Identifier with a proper Client ID Document and valid DPoP Proof (for a Solid client identifier) -the OP MUST return a DPoP-bound OIDC ID Token. +the OP MUST return A DPoP-bound OIDC ID Token. ## DPoP-bound OIDC ID Token ## {#tokens-id} @@ -452,14 +430,45 @@ requested resource. An OpenID Provider that conforms to the Solid-OIDC specification MUST advertise it in the OpenID Connect Discovery 1.0 [[!OIDC-DISCOVERY]] resource by including `webid` in its `scopes_supported` metadata property. -Additionally, the OP MUST include `client_credentials` in its `grant_types_supported` -metadata property to indicate support for non-interactive authentication -via the Client Credentials Grant (see [[#client-credentials]]). +
+ 
+        {
+            "scopes_supported": ["openid", "offline_access", "webid"]
+        }
+
+
+ +# Client Credentials Grant # {#client-credentials} + +NOTE: This sections borrows concepts from OAuth 2.0 [[!RFC6749]], while the rest of Solid-OIDC builds on top of OpenID +Connect Core 1.0 [[!OIDC-CORE]]. The section is likely to be extracted into a separate specification in the future. + +Authorization Servers MUST support the OAuth 2.0 Client Credentials Grant [[!RFC6749]] (Section 4.4) to enable +non-interactive authentication for scripts, automated agents, and server-to-server communication. + +NOTE: Scripts and bots can also use Solid-OIDC without Client Credentials via the refresh token flow, when supported by +the server. + +When using the Client Credentials Grant, the Client authenticates with the OP using a `client_id` and `client_secret` +pair previously obtained through client registration (either static or dynamic). The Client sends a token request to +the OP's token endpoint with `grant_type=client_credentials` and the `webid` scope. + +## Token Instantiation ## {#client-credentials-token-instantiation} + +During Token Instantiation [[#tokens]], if the [Client Credentials +Grant](https://www.rfc-editor.org/rfc/rfc6749#section-4.4) is used, the OP MUST validate the `client_id` and +`client_secret`. If valid, the OP MUST return A DPoP-bound OIDC ID Token. + +## Solid-OIDC Conformance Discovery ## {#client-credentials-discovery} + +For non-interactive use cases such as scripts, automated agents, and server-to-server communication, this specification +also requires that an OpenID Provider that conforms to the Solid-OIDC specification MUST advertise its support for the +[Client Credentials Grant](https://www.rfc-editor.org/rfc/rfc6749#section-4.4) in the OpenID Connect Discovery 1.0 +[OIDC.Discovery] resource by including `client_credentials` in its `grant_types_supported` metadata property. 
         {
-            "scopes_supported": ["openid", "offline_access", "webid"],
             "grant_types_supported": ["authorization_code", "refresh_token", "client_credentials"]
         }
From 3b8d430dfd53af746ee78ff3701f33a5c3b14936 Mon Sep 17 00:00:00 2001 From: Samu Lang Date: Fri, 6 Mar 2026 14:31:54 +0000 Subject: [PATCH 05/11] Update index.bs Co-authored-by: Jesse Wright <63333554+jeswr@users.noreply.github.com> --- index.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.bs b/index.bs index 47b9e18..c10e41c 100644 --- a/index.bs +++ b/index.bs @@ -457,7 +457,7 @@ the OP's token endpoint with `grant_type=client_credentials` and the `webid` sco During Token Instantiation [[#tokens]], if the [Client Credentials Grant](https://www.rfc-editor.org/rfc/rfc6749#section-4.4) is used, the OP MUST validate the `client_id` and -`client_secret`. If valid, the OP MUST return A DPoP-bound OIDC ID Token. +`client_secret`. If valid, the OP MUST return a DPoP-bound OIDC ID Token. ## Solid-OIDC Conformance Discovery ## {#client-credentials-discovery} From 0458856ce608a38d966ca1a1d2c1a3d6e4875eb4 Mon Sep 17 00:00:00 2001 From: Samu Lang Date: Fri, 6 Mar 2026 14:41:28 +0000 Subject: [PATCH 06/11] Add reference to refresh token flow --- index.bs | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/index.bs b/index.bs index c10e41c..0d57af6 100644 --- a/index.bs +++ b/index.bs @@ -446,8 +446,8 @@ Connect Core 1.0 [[!OIDC-CORE]]. The section is likely to be extracted into a se Authorization Servers MUST support the OAuth 2.0 Client Credentials Grant [[!RFC6749]] (Section 4.4) to enable non-interactive authentication for scripts, automated agents, and server-to-server communication. -NOTE: Scripts and bots can also use Solid-OIDC without Client Credentials via the refresh token flow, when supported by -the server. +NOTE: Scripts and bots can also use Solid-OIDC without Client Credentials via the [refresh token +flow](https://www.rfc-editor.org/rfc/rfc6749#section-1.5), when supported by the server. When using the Client Credentials Grant, the Client authenticates with the OP using a `client_id` and `client_secret` pair previously obtained through client registration (either static or dynamic). The Client sends a token request to From 69ea20f4f25da235008ff6170e1a03a51b9ef9f9 Mon Sep 17 00:00:00 2001 From: Samu Lang Date: Mon, 9 Mar 2026 14:31:13 +0000 Subject: [PATCH 07/11] Make Client Credentials authentication example non-normative and add RFC7523 reference --- index.bs | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/index.bs b/index.bs index 0d57af6..cdbf096 100644 --- a/index.bs +++ b/index.bs @@ -449,9 +449,15 @@ non-interactive authentication for scripts, automated agents, and server-to-serv NOTE: Scripts and bots can also use Solid-OIDC without Client Credentials via the [refresh token flow](https://www.rfc-editor.org/rfc/rfc6749#section-1.5), when supported by the server. -When using the Client Credentials Grant, the Client authenticates with the OP using a `client_id` and `client_secret` -pair previously obtained through client registration (either static or dynamic). The Client sends a token request to -the OP's token endpoint with `grant_type=client_credentials` and the `webid` scope. +*This section is non-normative* + +
+ When using the Client Credentials Grant, a Client could authenticate with the OP using a `client_id` + and `client_secret` pair previously obtained through client registration (either static or dynamic). The Client + sends a token request to the OP's token endpoint with `grant_type=client_credentials` and the `webid` scope. +
+ +NOTE: [[!RFC7523]] (Section 2.2) presents another way to handle authentication using JWTs. ## Token Instantiation ## {#client-credentials-token-instantiation} From 50e297d947a13b13185678c343309f3bcb79d96f Mon Sep 17 00:00:00 2001 From: Samu Lang Date: Mon, 9 Mar 2026 14:33:00 +0000 Subject: [PATCH 08/11] Generalize client authentication validation in Client Credentials grant --- index.bs | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/index.bs b/index.bs index cdbf096..90ab79b 100644 --- a/index.bs +++ b/index.bs @@ -462,8 +462,8 @@ NOTE: [[!RFC7523]] (Section 2.2) presents another way to handle authentication u ## Token Instantiation ## {#client-credentials-token-instantiation} During Token Instantiation [[#tokens]], if the [Client Credentials -Grant](https://www.rfc-editor.org/rfc/rfc6749#section-4.4) is used, the OP MUST validate the `client_id` and -`client_secret`. If valid, the OP MUST return a DPoP-bound OIDC ID Token. +Grant](https://www.rfc-editor.org/rfc/rfc6749#section-4.4) is used, the OP MUST validate the client's authentication +credentials. ## Solid-OIDC Conformance Discovery ## {#client-credentials-discovery} From 176406fcb560a1b71e1274dc88895add77b39ea2 Mon Sep 17 00:00:00 2001 From: Samu Lang Date: Mon, 9 Mar 2026 16:00:50 +0000 Subject: [PATCH 09/11] Clarify WebID binding requirement for Client Credentials Grant --- index.bs | 3 +++ 1 file changed, 3 insertions(+) diff --git a/index.bs b/index.bs index 90ab79b..56cbd68 100644 --- a/index.bs +++ b/index.bs @@ -449,6 +449,9 @@ non-interactive authentication for scripts, automated agents, and server-to-serv NOTE: Scripts and bots can also use Solid-OIDC without Client Credentials via the [refresh token flow](https://www.rfc-editor.org/rfc/rfc6749#section-1.5), when supported by the server. +When using the Client Credentials Grant, the AS must bind the `client_id` to the user who registered it and use that +user's WebID in the ID token. + *This section is non-normative*
From 9ea7a00b4a5024934f20e86870f1369a37174339 Mon Sep 17 00:00:00 2001 From: Samu Lang Date: Mon, 9 Mar 2026 17:25:04 +0000 Subject: [PATCH 10/11] Update index.bs Co-authored-by: elf Pavlik --- index.bs | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/index.bs b/index.bs index 56cbd68..8891519 100644 --- a/index.bs +++ b/index.bs @@ -449,8 +449,8 @@ non-interactive authentication for scripts, automated agents, and server-to-serv NOTE: Scripts and bots can also use Solid-OIDC without Client Credentials via the [refresh token flow](https://www.rfc-editor.org/rfc/rfc6749#section-1.5), when supported by the server. -When using the Client Credentials Grant, the AS must bind the `client_id` to the user who registered it and use that -user's WebID in the ID token. +When using the Client Credentials Grant, the Authorization Server must bind the `client_id` to the user who registered it and use that +user's WebID for the value of `webid` claim in the ID token. *This section is non-normative* From cb232b39398016caf55f89529facf4975574cd2e Mon Sep 17 00:00:00 2001 From: Samu Lang Date: Tue, 10 Mar 2026 09:48:23 +0000 Subject: [PATCH 11/11] Update index.bs Co-authored-by: Christoph Braun --- index.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.bs b/index.bs index 8891519..c4a85c3 100644 --- a/index.bs +++ b/index.bs @@ -456,7 +456,7 @@ user's WebID for the value of `webid` claim in the ID token.
When using the Client Credentials Grant, a Client could authenticate with the OP using a `client_id` - and `client_secret` pair previously obtained through client registration (either static or dynamic). The Client + and `client_secret` pair, which was previously obtained through client registration (either static or dynamic) by and bound to an authenticated user. The Client sends a token request to the OP's token endpoint with `grant_type=client_credentials` and the `webid` scope.