From 619daa57ff0cd9d4ee950fdb6bfee68648cc1951 Mon Sep 17 00:00:00 2001 From: Jesse Wright <63333554+jeswr@users.noreply.github.com> Date: Sun, 26 Apr 2026 17:40:12 +0100 Subject: [PATCH 1/5] =?UTF-8?q?Add=20=C2=A7Issuer=20Trust=20to=20Security?= =?UTF-8?q?=20Considerations?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Two non-normative bullets, both raised by @csarven on solid/specification#776 (https://github.com/solid/specification/pull/776#discussion_r3136804650): - Issuer trust is unconditional: a compromised / malicious / unavailable issuer can deny access, impersonate, or rewrite identity-related claims. - Many agents on a single issuer is a single point of failure: concentration risk grows with the issuer's user base. --- index.bs | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/index.bs b/index.bs index a45dc31..aee856b 100644 --- a/index.bs +++ b/index.bs @@ -525,6 +525,24 @@ data leaks should an attacker gain access to Client credentials. Clients are ephemeral, client registration is optional, and most Clients cannot keep secrets. These, among other factors, are what makes Client trust challenging. +## Issuer Trust ## {#security-issuer-trust} + +*This section is non-normative* + +A Solid-OIDC user's identity is asserted by the OpenID Provider listed in their WebID Profile via +`solid:oidcIssuer`. Implementers and end-users should consider the trust they place in that issuer: + +* **Issuer trust is unconditional.** Every assertion of the user's identity comes from the issuer. + The user is fully reliant on it; a compromised, malicious, or unavailable issuer can deny access + to all of the user's data, impersonate the user, or selectively rewrite the WebID's + identity-related claims. A high degree of trust in the chosen issuer is therefore necessary. + +* **Many agents on a single issuer is a single point of failure.** Where many agents share a single + issuer, that issuer is a concentration point: a single compromise, outage, or service-level + decision affects every agent that depends on it. Attacks tend to focus on major centralisations, + so concentration risk grows with the issuer's user base. Implementations offering accounts under + a shared issuer should plan for this risk. + # Privacy Considerations # {#privacy} ## OIDC ID Token Reuse ## {#privacy-token-reuse} From d5672c04abe6e96a9d1b015106039f0e8b12c638 Mon Sep 17 00:00:00 2001 From: Jesse Wright <63333554+jeswr@users.noreply.github.com> Date: Thu, 18 Jun 2026 16:35:41 +0100 Subject: [PATCH 2/5] Apply suggestions from code review Co-authored-by: Jesse Wright <63333554+jeswr@users.noreply.github.com> Co-authored-by: Christoph Braun --- index.bs | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/index.bs b/index.bs index aee856b..f3ad4a6 100644 --- a/index.bs +++ b/index.bs @@ -536,12 +536,10 @@ A Solid-OIDC user's identity is asserted by the OpenID Provider listed in their The user is fully reliant on it; a compromised, malicious, or unavailable issuer can deny access to all of the user's data, impersonate the user, or selectively rewrite the WebID's identity-related claims. A high degree of trust in the chosen issuer is therefore necessary. - -* **Many agents on a single issuer is a single point of failure.** Where many agents share a single - issuer, that issuer is a concentration point: a single compromise, outage, or service-level - decision affects every agent that depends on it. Attacks tend to focus on major centralisations, - so concentration risk grows with the issuer's user base. Implementations offering accounts under - a shared issuer should plan for this risk. +The authorization server has to choose to trust the identity provider selected by the user before granting access. This choice may be to delegate the choice completely to users, or to restrict the set of identity providers to a specific trust list. +* **Identity Provider as a Single Point of Failure.** When an agent has only one identity provider, only that single identity provider is able to assert the identity of the agent. In case this identity provider is unavailable, the agent is unable to authenticate itself. +Agents may have multiple identity providers. Having multiple identity providers can provide redundancy in the event of an outage of one identity provider service. The trade-off is that this increases the attack surface of malicious identity providers. +Where many agents share a single identity provider, that identity provider is a concentration point: a single compromise, outage, or service-level decision affects every agent that depends on it. Attacks tend to focus on major centralization, so concentration risk grows with the issuer's user base. Implementations offering accounts under a shared issuer should plan for this risk. # Privacy Considerations # {#privacy} From 0c65f38f4ef1ac563158442829b19ff7e6dca86a Mon Sep 17 00:00:00 2001 From: Jesse Wright <63333554+jeswr@users.noreply.github.com> Date: Thu, 18 Jun 2026 16:36:40 +0100 Subject: [PATCH 3/5] Update index.bs --- index.bs | 1465 +++++++++++++++++++++++++++--------------------------- 1 file changed, 731 insertions(+), 734 deletions(-) diff --git a/index.bs b/index.bs index f3ad4a6..31199cb 100644 --- a/index.bs +++ b/index.bs @@ -1,737 +1,734 @@ -
-Title: Solid-OIDC
-Boilerplate: issues-index no
-Shortname: solid-oidc
-Level: 1
-Status: CG-DRAFT
-Group: solidcg
-ED: https://solid.github.io/solid-oidc/
-TR: https://solidproject.org/TR/oidc
-!Created: July 16, 2021
-!Modified: [DATE]
-Repository: https://github.com/solid/solid-oidc
-Inline Github Issues: title
-Markup Shorthands: markdown yes
-Max ToC Depth: 2
-Editor: [Aaron Coburn](https://people.apache.org/~acoburn/#i) ([Inrupt](https://inrupt.com))
-Editor: [elf Pavlik](https://elf-pavlik.hackers4peace.net)
-Editor: Christoph Braun (Forschungszentrum Informatik (FZI))
-Former Editor: [Dmitri Zagidulin](http://computingjoy.com/)
-Former Editor: [Adam Migus](https://migusgroup.com/about/) ([The Migus Group](https://migusgroup.com/))
-Former Editor: [Ricky White](https://rickywhite.net) ([The Migus Group](https://migusgroup.com/))
-Test Suite: https://solid-contrib.github.io/solid-oidc-tests/
-Metadata Order: This version, Latest published version, Test Suite, Created, Modified, *, !*
-Abstract:
-  The Solid OpenID Connect (Solid-OIDC) specification defines how resource servers
-  verify the identity of relying parties and end users based on the authentication
-  performed by an OpenID provider. Solid-OIDC builds on top of OpenID Connect 1.0
-  for use within the Solid ecosystem.
-
- -# Introduction # {#intro} - -*This section is non-normative* - -The [Solid project](https://solidproject.org/) aims to change the way web applications work today to -improve privacy and user control of personal data by utilizing current standards, protocols, and -tools, to facilitate building extensible and modular decentralized applications based on -[Linked Data](https://www.w3.org/standards/semanticweb/data) principles. - -This specification is written for Authorization and Resource Server owners intending to implement -Solid-OIDC. It is also useful to Solid application developers charged with implementing a Solid-OIDC -client. - -The OAuth 2.0 [[!RFC6749]] and OpenID Connect Core 1.0 [[!OIDC-CORE]] web standards were -published in October 2012 and November 2014, respectively. Since publication they've seen rapid and -widespread adoption across the industry, in turn gaining extensive *"real-world"* data and -experience. The strengths of the protocols are now clear; however, in a changing eco-system where -privacy and control of digital identities are becoming more pressing concerns, it is also clear -that additional functionality is required. - -The additional functionality documented herein aims to address: - -1. Resource servers and their Authorization servers having no existing trust relationship with identity providers. -2. Ephemeral Clients as a first-order use-case. - -## Out of Scope ## {#intro-out-of-scope} - -*This section is non-normative* - -While the Solid-OIDC specification describes the structure of an ID Token for use in Solid, the definition of a global access token for use with Solid Resource Servers is beyond the scope of this specification. - -# Terminology # {#terms} - -*This section is non-normative* - -This specification uses the terms "access token", "authorization server", "resource server" (RS), "token endpoint", -"grant type", and "client" as defined by The OAuth 2.0 Authorization Framework [[!RFC6749]]. - -Throughout this specification, we will use the term OpenID Provider (OP) in line with the -terminology used in the Open ID Connect Core 1.0 specification (OIDC) [[!OIDC-CORE]]. -It should be noted that this is distinct from the entity referred to as an Authorization Server -by the OAuth 2.0 Authorization Framework (OAuth) [[!RFC6749]]. - -This specification also uses the following terms: - -
-
*WebID* as defined by [[!WEBID]] -
- A WebID is a URI with an HTTP or HTTPS scheme which denotes an Agent (Person, Organization, Group, - Device, etc.). - -
*JSON Web Token (JWT)* as defined by [[!RFC7519]] -
- A string representing a set of claims as a JSON object that is encoded in a JWS or JWE, enabling the - claims to be digitally signed or MACed and/or encrypted. - -
*JSON Web Key (JWK)* as defined by [[!RFC7517]] -
- A JSON object that represents a cryptographic key. The members of the object represent properties of - the key, including its value. - -
*Demonstration of Proof-of-Possession at the Application Layer (DPoP)* as defined by [[!DPOP]] -
- A mechanism for sender-constraining OAuth tokens via a proof-of-possession mechanism on the - application level. - -
*DPoP Proof* as defined by [[!DPOP]] -
- A DPoP proof is a JWT that is signed (using JWS) using a private key chosen by the client. - -
*Proof Key for Code Exchange (PKCE)* as defined by [[!RFC7636]] -
- An extension to the Authorization Code flow which mitigates the risk of an authorization code - interception attack. -
- -# Core Concepts # {#concepts} - -*This section is non-normative* - -In a decentralized ecosystem, such as Solid, an OP may be an identity-as-a-service vendor or, at -the other end of the spectrum, a user-controlled OP. In either case, the user may be authenticating -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 -preexisting trust relationships with the OP. This means that client registration, whether dynamic, -or static, is entirely optional. - -## WebIDs ## {#concepts-webids} - -*This section is non-normative* - -In line with Linked Data principles, a WebID is a HTTP URI that, -when dereferenced, resolves to a profile document that is structured data in an -[RDF 1.1 format](https://www.w3.org/TR/rdf11-concepts/). This profile document allows -people to link with others to grant access to identity resources as they see fit. WebIDs underpin -Solid and are used as a primary identifier for Users in this specification. - -# Basic Flow # {#basic-flow} - -*This section is non-normative* - -Details of the flow are available in [[!SOLID-OIDC-PRIMER]] - -
- -
Basic sequence of authenticating the user and the client.
-
- -# Client Identifiers # {#clientids} - -OAuth and OIDC require the Client application to identify itself to the OP and RS by presenting a -[client identifier](https://tools.ietf.org/html/rfc6749#section-2.2) (Client ID). Solid applications -SHOULD use a URI that can be dereferenced as a [Client ID Document](#clientids-document). - -Issue(78): - -## Client ID Document ## {#clientids-document} - -When a Client Identifier is dereferenced, the resource MUST be serialized as an `application/ld+json` document -unless content negotiation requires a different outcome. - -The serialized JSON form of a Client ID Document MUST use the normative JSON-LD `@context` -provided at `https://www.w3.org/ns/solid/oidc-context.jsonld` such that the resulting -document produces a JSON serialization of an OIDC client registration, per the -definition of client registration metadata from [[!RFC7591]] section 2. - -Also, the OP MUST dereference the Client ID Document and match any Client-supplied parameters -with the values in the Client ID Document. - -Further, the `redirect_uri` provided by the Client MUST be included in the registration `redirect_uris` -list. - -This example uses [JSON-LD ](https://www.w3.org/TR/json-ld/) for the Client ID Document: - -
-

https://app.example/id

- - 
-        {
-          "@context": ["https://www.w3.org/ns/solid/oidc-context.jsonld"],
-
-          "client_id": "https://app.example/id",
-          "client_name": "Solid Application Name",
-          "redirect_uris": ["https://app.example/callback"],
-          "post_logout_redirect_uris": ["https://app.example/logout"],
-          "client_uri": "https://app.example/",
-          "logo_uri" : "https://app.example/logo.png",
-          "tos_uri" : "https://app.example/tos.html",
-          "scope" : "openid profile offline_access webid",
-          "grant_types" : ["refresh_token","authorization_code"],
-          "response_types" : ["code"],
-          "default_max_age" : 3600,
-          "require_auth_time" : true
-        }
-
-
- -Issue(95): - -### JSON-LD context ### {#jsonld-context} - -This specification defines a JSON-LD context for use with OIDC Client ID Documents. This context is -available at `https://www.w3.org/ns/solid/oidc-context.jsonld`. Client ID Documents that reference -this JSON-LD context MUST use the HTTPS scheme. - -NOTE: the [Solid-OIDC Vocabulary](https://www.w3.org/ns/solid/oidc) that is part of this context uses the HTTP scheme. - -Full content of JSON-LD context can be also seen in [[#full-jsonld-context]] - -## OIDC Registration ## {#clientids-oidc} - -For non-dereferencable identifiers, the Client MUST present a `client_id` value that has been -registered with the OP via either OIDC dynamic or static registration. -See also [[!OIDC-DYNAMIC-CLIENT-REGISTRATION]]. - -When requesting Dynamic Client Registration, the Client MUST specify the `scope` in the metadata -and include `webid` in its value (space-separated list). - -
- 
-        {
-          "client_name": "S-C-A Browser Demo Client App",
-          "application_type": "web",
-          "redirect_uris": [
-            "https://dynamic-client.example/auth"
-          ],
-          "subject_type": "pairwise",
-          "token_endpoint_auth_method": "client_secret_basic",
-          "scope" : "openid profile offline_access webid"
-        }
-
-
- -# WebID Profile # {#webid-profile} - -Dereferencing the WebID URL results in a WebID Profile. - -Issue(76): - -## OIDC Issuer Discovery ## {#oidc-issuer-discovery} - -A WebID Profile lists the OpenID Providers who are trusted to issue tokens on behalf -of the agent who controls the WebID. This prevents a malicious OpenID Provider from issuing -otherwise valid ID Tokens for arbitrary WebIDs. An entity that verifies ID Tokens will use this -mechanism to determine if the issuer is authoritative for the given WebID. - -
- 
-      PREFIX solid: <http://www.w3.org/ns/solid/terms#>
-
-      <#id> solid:oidcIssuer <https://oidc.example> .
-
-
WebID Profile specifying an OIDC issuer
-
- -To discover a list of valid issuers, the WebID Profile MUST be checked for the existence of statements matching -
-  ?webid <http://www.w3.org/ns/solid/terms#oidcIssuer> ?iss .
-
-where `?webid` is set to WebID. The `?iss` will result in an IRI denoting valid issuer for that WebID. -The WebID Profile Document MUST include one or more statements matching the OIDC issuer pattern. - -Issue(80): - -Issue(92): - -Issue(91): - -### OIDC Issuer Discovery via Link Headers ### {#oidc-issuer-discovery-link-headers} - -A server hosting a WebID Profile Document MAY transmit the `http://www.w3.org/ns/solid/terms#oidcIssuer` -values via Link Headers, but they MUST be the same as in the RDF representation. -A client MUST treat the RDF in the body of the WebID Profile as canonical -but MAY use the Link Header values as an optimization. - -
- 
-        Link: <https://oidc.example>;
-              rel="http://www.w3.org/ns/solid/terms#oidcIssuer";
-              anchor="#id"
-
-
HTTP response Link Header (line breaks added for readibility)
-
- - -# Requesting the WebID Claim using a Scope Value # {#webid-scope} - -Solid-OIDC uses scope values, as defined in [[!RFC6749]] Section 3.3 and [[!OIDC-CORE]] Section 5.4 to specify -what information is made available as Claim Values. - -Solid-OIDC defines the following `scope` value for use with claim requests: - -
-
*webid* -
- REQUIRED. This scope requests access to the End-User's `webid` Claim. -
- - -# 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. -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. -The value of the `iss` parameter MUST be the Issuer Identifier of the OP, as defined in [[OIDC-CORE]]. -
- 
-HTTP/1.1 302 Found
-Location: https://client.example.com/callback?
-                                        code=n0esc392ae491076
-                                        &state=af0ifjsldkj
-                                        &iss=https%3A%2F%2Fidp.example.com
-
-
Example Authorization Response including the `iss` query parameter
-
- -Upon receiving the authorization response, the Client MUST validate the `iss` parameter: -* The Client MUST check for the presence of the `iss` parameter. -* The Client MUST verify that the `iss` value matches the Issuer Identifier of the OP to which the authorization request was sent. - -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. - - -# Token Instantiation # {#tokens} - -Assuming one of the following options - - 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. - -## DPoP-bound OIDC ID Token ## {#tokens-id} - -When requesting a DPoP-bound OIDC ID Token, the Client MUST send a DPoP proof JWT -that is valid according to the [[DPOP#section-5]]. The DPoP proof JWT is used to -bind the OIDC ID Token to a public key. See also: [[!DPOP]]. - -With the `webid` scope, the DPoP-bound OIDC ID Token payload MUST contain these claims: - * `webid` — The WebID claim MUST be the user's WebID. - * `iss` — The issuer claim MUST be a valid URL of the OP - instantiating this token. - * `aud` — The audience claim MUST be an array of values. - The values MUST include the authorized party claim `azp` - and the string `solid`. - In the decentralized world - of Solid-OIDC, the audience of an ID Token is not only the client (`azp`), - but also any Solid Authorization Server at any accessible address - on the world wide web (`solid`). See also: [[RFC7519#section-4.1.3]]. - * `azp` - The authorized party claim is used to identify the client - (See also: [section 5. Client Identifiers](#clientids)). - * `iat` — The issued-at claim is the time at which the DPoP-bound - OIDC ID Token was issued. - * `exp` — The expiration claim is the time at which the DPoP-bound - OIDC ID Token becomes invalid. - * `cnf` — The confirmation claim is used to identify the DPoP Public - Key bound to the OIDC ID Token. See also: [[DPOP#section-7]]. - -
-

An example OIDC ID Token: - - 

-        {
-            "webid": "https://janedoe.com/web#id",
-            "iss": "https://idp.example.com",
-            "sub": "janedoe",
-            "aud": ["https://client.example.com/client_id", "solid"],
-            "azp": "https://client.example.com/client_id",
-            "iat": 1311280970,
-            "exp": 1311281970,
-            "cnf":{
-              "jkt":"0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I"
-            }
-        }
-
-
- -Issue(26): - -Issue(47): - -### ID Token Validation ### {#id-token-validation} - -An ID Token must be validated according to [OIDC-CORE, Section 3.1.3.7](https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation) - -The Verifying party MUST perform [[#oidc-issuer-discovery]] using the value of the `webid` claim -to dereference the WebID Profile Document. - -Unless the verifying party acquires OP keys through some other means, or it chooses to reject tokens issued by this OP, -the verifying party MUST follow OpenID Connect Discovery 1.0 [[!OIDC-DISCOVERY]] to find an OP's signing keys (JWK). - -# Resource Access # {#resource} - -## Authorization Server Discovery ## {#authorization-server-discovery} - -When a Client performs an unauthenticated request to a protected resource, -the Resource Server MUST respond with the HTTP 401 status code, -and a WWW-Authenticate HTTP header. See also: [[RFC9110]](11.6.1. WWW-Authenticate) - -The WWW-Authenticate HTTP header MUST include an as_uri -parameter unless the authentication scheme requires a different mechanism -for discovering an associated authorization server. - -Authorization Servers SHOULD implement User-Managed Access (UMA) 2.0 Grant for -OAuth 2.0 Authorization [[!UMA]]. - -## Obtaining an Access Token ## {#obtaining-access-token} - -For Authorization Servers that conform to [[!UMA]], the -http://openid.net/specs/openid-connect-core-1_0.html#IDToken profile MUST -be supported. This profile MUST be advertised in the uma_profiles_supported -metadata of the Authorization Server discovery document [[UMA#rfc.section.2]]. - -When using the http://openid.net/specs/openid-connect-core-1_0.html#IDToken -profile with an UMA-based Authorization Server, the Authorization Server MUST be capable -of exchanging a valid Solid-OIDC ID Token [[#tokens-id]] for an OAuth 2.0 Access Token. - -Note: Clients can push additional claims by requesting an upgraded RPT [[UMA#rfc.section.3.3.1]] - -Authorization Server MUST pefrom [[#dpop-validation]] and [[#id-token-validation]] - -## DPoP Validation ## {#dpop-validation} - -A DPoP Proof that is valid according to -[DPoP Internet-Draft, Section 4.3](https://tools.ietf.org/html/draft-ietf-oauth-dpop-04#section-4.3), -MUST be present when a DPoP-bound OIDC ID Token is used. - -The DPoP-bound OIDC ID Token MUST be validated according to -[DPoP Internet-Draft, Section 6](https://tools.ietf.org/html/draft-ietf-oauth-dpop-04#section-6), -but the AS MAY perform additional verification in order to determine whether to grant access to the -requested resource. - -# Solid-OIDC Conformance Discovery # {#discovery} - -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. - -
- 
-        {
-            "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 SHOULD 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](https://www.rfc-editor.org/rfc/rfc6749#section-1.5), when supported by the server. - -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* - -
- When using the Client Credentials Grant, a Client could authenticate with the OP using a `client_id` - 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. -
- -NOTE: [[!RFC7523]] (Section 2.2) presents another way to handle authentication using JWTs. - -## 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's authentication -credentials. - -## Solid-OIDC Conformance Discovery ## {#client-credentials-discovery} - -For non-interactive use cases such as scripts, automated agents, and server-to-server communication, an OpenID Provider -that supports the [Client Credentials Grant](https://www.rfc-editor.org/rfc/rfc6749#section-4.4) MUST advertise that -support in the OpenID Connect Discovery 1.0 [OIDC.Discovery] resource by including `client_credentials` in its -`grant_types_supported` metadata property. - -
- 
-        {
-            "grant_types_supported": ["authorization_code", "refresh_token", "client_credentials"]
-        }
-
-
- -# Security Considerations # {#security} - -*This section is non-normative* - -As this specification builds upon existing web standards, security considerations from OAuth, OIDC, -PKCE, and the DPoP specifications may also apply unless otherwise indicated. The following -considerations should be reviewed by implementors and system/s architects of this specification. - -Some of the references within this specification point to documents with a -Living Standard or Draft status, meaning their contents can still change over -time. It is advised to monitor these documents, as such changes might have -security implications. - -In addition to above considerations, implementors should consider the Security -Considerations in context of the Solid Protocol [[!SOLID-PROTOCOL]]. - -## TLS Requirements ## {#security-tls} - -All TLS requirements outlined in [[BCP195]] apply to this -specification. - -All tokens, Client, and User credentials MUST only be transmitted over TLS. - -## Client IDs ## {#security-client-ids} - -An AS SHOULD assign a fixed set of low trust policies to any client identified as anonymous. - -Implementors SHOULD expire ephemeral Client IDs that are kept in server storage to mitigate the -potential for a bad actor to fill server storage with unexpired or otherwise useless Client IDs. - -## Client Secrets ## {#security-client-secrets} - -Client secrets SHOULD NOT be stored in browser local storage. Doing so will increase the risk of -data leaks should an attacker gain access to Client credentials. - -## Client Trust ## {#security-client-trust} - -*This section is non-normative* - -Clients are ephemeral, client registration is optional, and most Clients cannot keep secrets. These, -among other factors, are what makes Client trust challenging. - -## Issuer Trust ## {#security-issuer-trust} - -*This section is non-normative* - -A Solid-OIDC user's identity is asserted by the OpenID Provider listed in their WebID Profile via -`solid:oidcIssuer`. Implementers and end-users should consider the trust they place in that issuer: - -* **Issuer trust is unconditional.** Every assertion of the user's identity comes from the issuer. - The user is fully reliant on it; a compromised, malicious, or unavailable issuer can deny access - to all of the user's data, impersonate the user, or selectively rewrite the WebID's - identity-related claims. A high degree of trust in the chosen issuer is therefore necessary. -The authorization server has to choose to trust the identity provider selected by the user before granting access. This choice may be to delegate the choice completely to users, or to restrict the set of identity providers to a specific trust list. +
+Title: Solid-OIDC
+Boilerplate: issues-index no
+Shortname: solid-oidc
+Level: 1
+Status: CG-DRAFT
+Group: solidcg
+ED: https://solid.github.io/solid-oidc/
+TR: https://solidproject.org/TR/oidc
+!Created: July 16, 2021
+!Modified: [DATE]
+Repository: https://github.com/solid/solid-oidc
+Inline Github Issues: title
+Markup Shorthands: markdown yes
+Max ToC Depth: 2
+Editor: [Aaron Coburn](https://people.apache.org/~acoburn/#i) ([Inrupt](https://inrupt.com))
+Editor: [elf Pavlik](https://elf-pavlik.hackers4peace.net)
+Editor: Christoph Braun (Forschungszentrum Informatik (FZI))
+Former Editor: [Dmitri Zagidulin](http://computingjoy.com/)
+Former Editor: [Adam Migus](https://migusgroup.com/about/) ([The Migus Group](https://migusgroup.com/))
+Former Editor: [Ricky White](https://rickywhite.net) ([The Migus Group](https://migusgroup.com/))
+Test Suite: https://solid-contrib.github.io/solid-oidc-tests/
+Metadata Order: This version, Latest published version, Test Suite, Created, Modified, *, !*
+Abstract:
+  The Solid OpenID Connect (Solid-OIDC) specification defines how resource servers
+  verify the identity of relying parties and end users based on the authentication
+  performed by an OpenID provider. Solid-OIDC builds on top of OpenID Connect 1.0
+  for use within the Solid ecosystem.
+
+ +# Introduction # {#intro} + +*This section is non-normative* + +The [Solid project](https://solidproject.org/) aims to change the way web applications work today to +improve privacy and user control of personal data by utilizing current standards, protocols, and +tools, to facilitate building extensible and modular decentralized applications based on +[Linked Data](https://www.w3.org/standards/semanticweb/data) principles. + +This specification is written for Authorization and Resource Server owners intending to implement +Solid-OIDC. It is also useful to Solid application developers charged with implementing a Solid-OIDC +client. + +The OAuth 2.0 [[!RFC6749]] and OpenID Connect Core 1.0 [[!OIDC-CORE]] web standards were +published in October 2012 and November 2014, respectively. Since publication they've seen rapid and +widespread adoption across the industry, in turn gaining extensive *"real-world"* data and +experience. The strengths of the protocols are now clear; however, in a changing eco-system where +privacy and control of digital identities are becoming more pressing concerns, it is also clear +that additional functionality is required. + +The additional functionality documented herein aims to address: + +1. Resource servers and their Authorization servers having no existing trust relationship with identity providers. +2. Ephemeral Clients as a first-order use-case. + +## Out of Scope ## {#intro-out-of-scope} + +*This section is non-normative* + +While the Solid-OIDC specification describes the structure of an ID Token for use in Solid, the definition of a global access token for use with Solid Resource Servers is beyond the scope of this specification. + +# Terminology # {#terms} + +*This section is non-normative* + +This specification uses the terms "access token", "authorization server", "resource server" (RS), "token endpoint", +"grant type", and "client" as defined by The OAuth 2.0 Authorization Framework [[!RFC6749]]. + +Throughout this specification, we will use the term OpenID Provider (OP) in line with the +terminology used in the Open ID Connect Core 1.0 specification (OIDC) [[!OIDC-CORE]]. +It should be noted that this is distinct from the entity referred to as an Authorization Server +by the OAuth 2.0 Authorization Framework (OAuth) [[!RFC6749]]. + +This specification also uses the following terms: + +
+
*WebID* as defined by [[!WEBID]] +
+ A WebID is a URI with an HTTP or HTTPS scheme which denotes an Agent (Person, Organization, Group, + Device, etc.). + +
*JSON Web Token (JWT)* as defined by [[!RFC7519]] +
+ A string representing a set of claims as a JSON object that is encoded in a JWS or JWE, enabling the + claims to be digitally signed or MACed and/or encrypted. + +
*JSON Web Key (JWK)* as defined by [[!RFC7517]] +
+ A JSON object that represents a cryptographic key. The members of the object represent properties of + the key, including its value. + +
*Demonstration of Proof-of-Possession at the Application Layer (DPoP)* as defined by [[!DPOP]] +
+ A mechanism for sender-constraining OAuth tokens via a proof-of-possession mechanism on the + application level. + +
*DPoP Proof* as defined by [[!DPOP]] +
+ A DPoP proof is a JWT that is signed (using JWS) using a private key chosen by the client. + +
*Proof Key for Code Exchange (PKCE)* as defined by [[!RFC7636]] +
+ An extension to the Authorization Code flow which mitigates the risk of an authorization code + interception attack. +
+ +# Core Concepts # {#concepts} + +*This section is non-normative* + +In a decentralized ecosystem, such as Solid, an OP may be an identity-as-a-service vendor or, at +the other end of the spectrum, a user-controlled OP. In either case, the user may be authenticating +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 +preexisting trust relationships with the OP. This means that client registration, whether dynamic, +or static, is entirely optional. + +## WebIDs ## {#concepts-webids} + +*This section is non-normative* + +In line with Linked Data principles, a WebID is a HTTP URI that, +when dereferenced, resolves to a profile document that is structured data in an +[RDF 1.1 format](https://www.w3.org/TR/rdf11-concepts/). This profile document allows +people to link with others to grant access to identity resources as they see fit. WebIDs underpin +Solid and are used as a primary identifier for Users in this specification. + +# Basic Flow # {#basic-flow} + +*This section is non-normative* + +Details of the flow are available in [[!SOLID-OIDC-PRIMER]] + +
+ +
Basic sequence of authenticating the user and the client.
+
+ +# Client Identifiers # {#clientids} + +OAuth and OIDC require the Client application to identify itself to the OP and RS by presenting a +[client identifier](https://tools.ietf.org/html/rfc6749#section-2.2) (Client ID). Solid applications +SHOULD use a URI that can be dereferenced as a [Client ID Document](#clientids-document). + +Issue(78): + +## Client ID Document ## {#clientids-document} + +When a Client Identifier is dereferenced, the resource MUST be serialized as an `application/ld+json` document +unless content negotiation requires a different outcome. + +The serialized JSON form of a Client ID Document MUST use the normative JSON-LD `@context` +provided at `https://www.w3.org/ns/solid/oidc-context.jsonld` such that the resulting +document produces a JSON serialization of an OIDC client registration, per the +definition of client registration metadata from [[!RFC7591]] section 2. + +Also, the OP MUST dereference the Client ID Document and match any Client-supplied parameters +with the values in the Client ID Document. + +Further, the `redirect_uri` provided by the Client MUST be included in the registration `redirect_uris` +list. + +This example uses [JSON-LD ](https://www.w3.org/TR/json-ld/) for the Client ID Document: + +
+

https://app.example/id

+ + 
+        {
+          "@context": ["https://www.w3.org/ns/solid/oidc-context.jsonld"],
+
+          "client_id": "https://app.example/id",
+          "client_name": "Solid Application Name",
+          "redirect_uris": ["https://app.example/callback"],
+          "post_logout_redirect_uris": ["https://app.example/logout"],
+          "client_uri": "https://app.example/",
+          "logo_uri" : "https://app.example/logo.png",
+          "tos_uri" : "https://app.example/tos.html",
+          "scope" : "openid profile offline_access webid",
+          "grant_types" : ["refresh_token","authorization_code"],
+          "response_types" : ["code"],
+          "default_max_age" : 3600,
+          "require_auth_time" : true
+        }
+
+
+ +Issue(95): + +### JSON-LD context ### {#jsonld-context} + +This specification defines a JSON-LD context for use with OIDC Client ID Documents. This context is +available at `https://www.w3.org/ns/solid/oidc-context.jsonld`. Client ID Documents that reference +this JSON-LD context MUST use the HTTPS scheme. + +NOTE: the [Solid-OIDC Vocabulary](https://www.w3.org/ns/solid/oidc) that is part of this context uses the HTTP scheme. + +Full content of JSON-LD context can be also seen in [[#full-jsonld-context]] + +## OIDC Registration ## {#clientids-oidc} + +For non-dereferencable identifiers, the Client MUST present a `client_id` value that has been +registered with the OP via either OIDC dynamic or static registration. +See also [[!OIDC-DYNAMIC-CLIENT-REGISTRATION]]. + +When requesting Dynamic Client Registration, the Client MUST specify the `scope` in the metadata +and include `webid` in its value (space-separated list). + +
+ 
+        {
+          "client_name": "S-C-A Browser Demo Client App",
+          "application_type": "web",
+          "redirect_uris": [
+            "https://dynamic-client.example/auth"
+          ],
+          "subject_type": "pairwise",
+          "token_endpoint_auth_method": "client_secret_basic",
+          "scope" : "openid profile offline_access webid"
+        }
+
+
+ +# WebID Profile # {#webid-profile} + +Dereferencing the WebID URL results in a WebID Profile. + +Issue(76): + +## OIDC Issuer Discovery ## {#oidc-issuer-discovery} + +A WebID Profile lists the OpenID Providers who are trusted to issue tokens on behalf +of the agent who controls the WebID. This prevents a malicious OpenID Provider from issuing +otherwise valid ID Tokens for arbitrary WebIDs. An entity that verifies ID Tokens will use this +mechanism to determine if the issuer is authoritative for the given WebID. + +
+ 
+      PREFIX solid: <http://www.w3.org/ns/solid/terms#>
+
+      <#id> solid:oidcIssuer <https://oidc.example> .
+
+
WebID Profile specifying an OIDC issuer
+
+ +To discover a list of valid issuers, the WebID Profile MUST be checked for the existence of statements matching +
+  ?webid <http://www.w3.org/ns/solid/terms#oidcIssuer> ?iss .
+
+where `?webid` is set to WebID. The `?iss` will result in an IRI denoting valid issuer for that WebID. +The WebID Profile Document MUST include one or more statements matching the OIDC issuer pattern. + +Issue(80): + +Issue(92): + +Issue(91): + +### OIDC Issuer Discovery via Link Headers ### {#oidc-issuer-discovery-link-headers} + +A server hosting a WebID Profile Document MAY transmit the `http://www.w3.org/ns/solid/terms#oidcIssuer` +values via Link Headers, but they MUST be the same as in the RDF representation. +A client MUST treat the RDF in the body of the WebID Profile as canonical +but MAY use the Link Header values as an optimization. + +
+ 
+        Link: <https://oidc.example>;
+              rel="http://www.w3.org/ns/solid/terms#oidcIssuer";
+              anchor="#id"
+
+
HTTP response Link Header (line breaks added for readibility)
+
+ + +# Requesting the WebID Claim using a Scope Value # {#webid-scope} + +Solid-OIDC uses scope values, as defined in [[!RFC6749]] Section 3.3 and [[!OIDC-CORE]] Section 5.4 to specify +what information is made available as Claim Values. + +Solid-OIDC defines the following `scope` value for use with claim requests: + +
+
*webid* +
+ REQUIRED. This scope requests access to the End-User's `webid` Claim. +
+ + +# 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. +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. +The value of the `iss` parameter MUST be the Issuer Identifier of the OP, as defined in [[OIDC-CORE]]. +
+ 
+HTTP/1.1 302 Found
+Location: https://client.example.com/callback?
+                                        code=n0esc392ae491076
+                                        &state=af0ifjsldkj
+                                        &iss=https%3A%2F%2Fidp.example.com
+
+
Example Authorization Response including the `iss` query parameter
+
+ +Upon receiving the authorization response, the Client MUST validate the `iss` parameter: +* The Client MUST check for the presence of the `iss` parameter. +* The Client MUST verify that the `iss` value matches the Issuer Identifier of the OP to which the authorization request was sent. + +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. + + +# Token Instantiation # {#tokens} + +Assuming one of the following options + - 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. + +## DPoP-bound OIDC ID Token ## {#tokens-id} + +When requesting a DPoP-bound OIDC ID Token, the Client MUST send a DPoP proof JWT +that is valid according to the [[DPOP#section-5]]. The DPoP proof JWT is used to +bind the OIDC ID Token to a public key. See also: [[!DPOP]]. + +With the `webid` scope, the DPoP-bound OIDC ID Token payload MUST contain these claims: + * `webid` — The WebID claim MUST be the user's WebID. + * `iss` — The issuer claim MUST be a valid URL of the OP + instantiating this token. + * `aud` — The audience claim MUST be an array of values. + The values MUST include the authorized party claim `azp` + and the string `solid`. + In the decentralized world + of Solid-OIDC, the audience of an ID Token is not only the client (`azp`), + but also any Solid Authorization Server at any accessible address + on the world wide web (`solid`). See also: [[RFC7519#section-4.1.3]]. + * `azp` - The authorized party claim is used to identify the client + (See also: [section 5. Client Identifiers](#clientids)). + * `iat` — The issued-at claim is the time at which the DPoP-bound + OIDC ID Token was issued. + * `exp` — The expiration claim is the time at which the DPoP-bound + OIDC ID Token becomes invalid. + * `cnf` — The confirmation claim is used to identify the DPoP Public + Key bound to the OIDC ID Token. See also: [[DPOP#section-7]]. + +
+

An example OIDC ID Token: + + 

+        {
+            "webid": "https://janedoe.com/web#id",
+            "iss": "https://idp.example.com",
+            "sub": "janedoe",
+            "aud": ["https://client.example.com/client_id", "solid"],
+            "azp": "https://client.example.com/client_id",
+            "iat": 1311280970,
+            "exp": 1311281970,
+            "cnf":{
+              "jkt":"0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I"
+            }
+        }
+
+
+ +Issue(26): + +Issue(47): + +### ID Token Validation ### {#id-token-validation} + +An ID Token must be validated according to [OIDC-CORE, Section 3.1.3.7](https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation) + +The Verifying party MUST perform [[#oidc-issuer-discovery]] using the value of the `webid` claim +to dereference the WebID Profile Document. + +Unless the verifying party acquires OP keys through some other means, or it chooses to reject tokens issued by this OP, +the verifying party MUST follow OpenID Connect Discovery 1.0 [[!OIDC-DISCOVERY]] to find an OP's signing keys (JWK). + +# Resource Access # {#resource} + +## Authorization Server Discovery ## {#authorization-server-discovery} + +When a Client performs an unauthenticated request to a protected resource, +the Resource Server MUST respond with the HTTP 401 status code, +and a WWW-Authenticate HTTP header. See also: [[RFC9110]](11.6.1. WWW-Authenticate) + +The WWW-Authenticate HTTP header MUST include an as_uri +parameter unless the authentication scheme requires a different mechanism +for discovering an associated authorization server. + +Authorization Servers SHOULD implement User-Managed Access (UMA) 2.0 Grant for +OAuth 2.0 Authorization [[!UMA]]. + +## Obtaining an Access Token ## {#obtaining-access-token} + +For Authorization Servers that conform to [[!UMA]], the +http://openid.net/specs/openid-connect-core-1_0.html#IDToken profile MUST +be supported. This profile MUST be advertised in the uma_profiles_supported +metadata of the Authorization Server discovery document [[UMA#rfc.section.2]]. + +When using the http://openid.net/specs/openid-connect-core-1_0.html#IDToken +profile with an UMA-based Authorization Server, the Authorization Server MUST be capable +of exchanging a valid Solid-OIDC ID Token [[#tokens-id]] for an OAuth 2.0 Access Token. + +Note: Clients can push additional claims by requesting an upgraded RPT [[UMA#rfc.section.3.3.1]] + +Authorization Server MUST pefrom [[#dpop-validation]] and [[#id-token-validation]] + +## DPoP Validation ## {#dpop-validation} + +A DPoP Proof that is valid according to +[DPoP Internet-Draft, Section 4.3](https://tools.ietf.org/html/draft-ietf-oauth-dpop-04#section-4.3), +MUST be present when a DPoP-bound OIDC ID Token is used. + +The DPoP-bound OIDC ID Token MUST be validated according to +[DPoP Internet-Draft, Section 6](https://tools.ietf.org/html/draft-ietf-oauth-dpop-04#section-6), +but the AS MAY perform additional verification in order to determine whether to grant access to the +requested resource. + +# Solid-OIDC Conformance Discovery # {#discovery} + +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. + +
+ 
+        {
+            "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 SHOULD 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](https://www.rfc-editor.org/rfc/rfc6749#section-1.5), when supported by the server. + +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* + +
+ When using the Client Credentials Grant, a Client could authenticate with the OP using a `client_id` + 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. +
+ +NOTE: [[!RFC7523]] (Section 2.2) presents another way to handle authentication using JWTs. + +## 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's authentication +credentials. + +## Solid-OIDC Conformance Discovery ## {#client-credentials-discovery} + +For non-interactive use cases such as scripts, automated agents, and server-to-server communication, an OpenID Provider +that supports the [Client Credentials Grant](https://www.rfc-editor.org/rfc/rfc6749#section-4.4) MUST advertise that +support in the OpenID Connect Discovery 1.0 [OIDC.Discovery] resource by including `client_credentials` in its +`grant_types_supported` metadata property. + +
+ 
+        {
+            "grant_types_supported": ["authorization_code", "refresh_token", "client_credentials"]
+        }
+
+
+ +# Security Considerations # {#security} + +*This section is non-normative* + +As this specification builds upon existing web standards, security considerations from OAuth, OIDC, +PKCE, and the DPoP specifications may also apply unless otherwise indicated. The following +considerations should be reviewed by implementors and system/s architects of this specification. + +Some of the references within this specification point to documents with a +Living Standard or Draft status, meaning their contents can still change over +time. It is advised to monitor these documents, as such changes might have +security implications. + +In addition to above considerations, implementors should consider the Security +Considerations in context of the Solid Protocol [[!SOLID-PROTOCOL]]. + +## TLS Requirements ## {#security-tls} + +All TLS requirements outlined in [[BCP195]] apply to this +specification. + +All tokens, Client, and User credentials MUST only be transmitted over TLS. + +## Client IDs ## {#security-client-ids} + +An AS SHOULD assign a fixed set of low trust policies to any client identified as anonymous. + +Implementors SHOULD expire ephemeral Client IDs that are kept in server storage to mitigate the +potential for a bad actor to fill server storage with unexpired or otherwise useless Client IDs. + +## Client Secrets ## {#security-client-secrets} + +Client secrets SHOULD NOT be stored in browser local storage. Doing so will increase the risk of +data leaks should an attacker gain access to Client credentials. + +## Client Trust ## {#security-client-trust} + +*This section is non-normative* + +Clients are ephemeral, client registration is optional, and most Clients cannot keep secrets. These, +among other factors, are what makes Client trust challenging. + +## Issuer Trust ## {#security-issuer-trust} + +*This section is non-normative* + +A Solid-OIDC user's identity is asserted by the OpenID Provider listed in their WebID Profile via +`solid:oidcIssuer`. Implementers and end-users should consider the trust they place in that issuer: + +* **User trusts identity provider to be honest.** The user's chosen identity provider is able to assert the identity of the user in an issued identity token. The user relies on the identity provider to obtain such identity token and trusts the identity provider not to issue such token of the user's identity to a different user or to use that token themselves. A compromised or malicious identity provider is able to let other malicious agents impersonate the user or to impersonate the user themself. If the user's identity provider is unavailable, the user is unable to obtain an identity token, which might lead the user to be unable to access data that requires authentication and thereby implicitly denying access to data. A high degree of trust in the chosen identity provider is therefore necessary. +The authorization server has to choose to trust the identity provider selected by the user before granting access. This choice may be to delegate the choice completely to users, or to restrict the set of identity providers to a specific trust list. * **Identity Provider as a Single Point of Failure.** When an agent has only one identity provider, only that single identity provider is able to assert the identity of the agent. In case this identity provider is unavailable, the agent is unable to authenticate itself. Agents may have multiple identity providers. Having multiple identity providers can provide redundancy in the event of an outage of one identity provider service. The trade-off is that this increases the attack surface of malicious identity providers. Where many agents share a single identity provider, that identity provider is a concentration point: a single compromise, outage, or service-level decision affects every agent that depends on it. Attacks tend to focus on major centralization, so concentration risk grows with the issuer's user base. Implementations offering accounts under a shared issuer should plan for this risk. - -# Privacy Considerations # {#privacy} - -## OIDC ID Token Reuse ## {#privacy-token-reuse} - -*This section is non-normative* - -With JWTs being extendable by design, there is potential for a privacy breach if OIDC ID Tokens get -reused across multiple authorization servers. It is not unimaginable that a custom claim is added to the -OIDC ID Token on instantiation. This addition may unintentionally give other authorization servers -consuming the OIDC ID Token information about the user that they may not wish to share outside of the -intended AS. - -# Acknowledgments # {#acknowledgments} - -*This section is non-normative* - -The Solid Community Group would like to thank the following individuals for reviewing and providing -feedback on the specification (in alphabetical order): - -Tim Berners-Lee, Justin Bingham, Sarven Capadisli, Aaron Coburn, Matthias Evering, Jamie Fiedler, -Michiel de Jong, Ted Thibodeau Jr, Kjetil Kjernsmo, Mitzi László, Pat McBennett, Adam Migus, Jackson Morgan, Davi -Ottenheimer, Justin Richer, severin-dsr, Henry Story, Michael Thornburgh, Emmet Townsend, Ruben -Verborgh, Ricky White, Paul Worrall, Dmitri Zagidulin. - -# Appendix A: Full JSON-LD context # {#full-jsonld-context} - -The JSON-LD context is defined as: - -
-  {
-    "@context": {
-      "@version": 1.1,
-      "@protected": true,
-      "oidc": "http://www.w3.org/ns/solid/oidc#",
-      "xsd": "http://www.w3.org/2001/XMLSchema#",
-      "client_id": {
-        "@id": "@id",
-        "@type": "@id"
-      },
-      "client_uri": {
-        "@id": "oidc:client_uri",
-        "@type": "@id"
-      },
-      "logo_uri": {
-        "@id": "oidc:logo_uri",
-        "@type": "@id"
-      },
-      "policy_uri": {
-        "@id": "oidc:policy_uri",
-        "@type": "@id"
-      },
-      "tos_uri": {
-        "@id": "oidc:tos_uri",
-        "@type": "@id"
-      },
-      "redirect_uris": {
-        "@id": "oidc:redirect_uris",
-        "@type": "@id",
-        "@container": [
-          "@id",
-          "@set"
-        ]
-      },
-      "require_auth_time": {
-        "@id": "oidc:require_auth_time",
-        "@type": "xsd:boolean"
-      },
-      "default_max_age": {
-        "@id": "oidc:default_max_age",
-        "@type": "xsd:integer"
-      },
-      "application_type": {
-        "@id": "oidc:application_type"
-      },
-      "client_name": {
-        "@id": "oidc:client_name"
-      },
-      "contacts": {
-        "@id": "oidc:contacts"
-      },
-      "grant_types": {
-        "@id": "oidc:grant_types"
-      },
-      "response_types": {
-        "@id": "oidc:response_types"
-      },
-      "scope": {
-        "@id": "oidc:scope"
-      },
-      "token_endpoint_auth_method": {
-        "@id": "oidc:token_endpoint_auth_method"
-      }
-    }
-  }
-
- -
-{
-    "DPOP": {
-        "authors": [
-            "D. Fett",
-            "B. Campbell",
-            "J. Bradley",
-            "T. Lodderstedt",
-            "M. Jones",
-            "D. Waite"
-        ],
-        "href": "https://tools.ietf.org/html/draft-ietf-oauth-dpop",
-        "title": "OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer (DPoP)",
-        "publisher": "IETF"
-    },
-    "OIDC-CORE": {
-        "authors": [
-            "N. Sakimura",
-            "J. Bradley",
-            "M. Jones",
-            "B. de Medeiros",
-            "C. Mortimore"
-        ],
-        "href": "https://openid.net/specs/openid-connect-core-1_0.html",
-        "title": "OpenID Connect Core 1.0",
-        "publisher": "The OpenID Foundation"
-    },
-    "OIDC-DISCOVERY": {
-        "authors": [
-            "N. Sakimura",
-            "J. Bradley",
-            "M. Jones",
-            "E. Jay"
-        ],
-        "href": "https://openid.net/specs/openid-connect-discovery-1_0.html",
-        "title": "OpenID Connect Discovery 1.0",
-        "publisher": "The OpenID Foundation"
-    },
-    "OIDC-DYNAMIC-CLIENT-REGISTRATION": {
-        "authors": [
-            "N. Sakimura",
-            "J. Bradley",
-            "M.B. Jones"
-        ],
-        "href": "https://openid.net/specs/openid-connect-registration-1_0.html",
-        "title": "OpenID Connect Dynamic Client Registration 1.0",
-        "publisher": "The OpenID Foundation"
-    },
-    "SOLID-PROTOCOL": {
-        "authors": [
-            "Sarven Capadisli",
-            "Tim Berners-Lee",
-            "Ruben Verborgh",
-            "Kjetil Kjernsmo",
-            "Justin Bingham",
-            "Dmitri Zagidulin"
-        ],
-        "href": "https://solidproject.org/TR/protocol",
-        "title": "Solid Protocol",
-        "publisher": "W3C Solid Community Group"
-    },
-    "SOLID-OIDC-PRIMER": {
-        "authors": [
-            "Jackson Morgan",
-            "Aaron Coburn",
-            "Matthieu Bosquet"
-        ],
-        "href": "https://solid.github.io/solid-oidc/primer/",
-        "title": "Solid-OIDC Primer",
-        "publisher": "W3C Solid Community Group"
-    },
-    "WEBID": {
-        "authors": [
-            "Andrei Sambra",
-            "Henry Story",
-            "Tim Berners-Lee"
-        ],
-        "href": "https://www.w3.org/2005/Incubator/webid/spec/identity/",
-        "title": "WebID 1.0",
-        "publisher": "WebID Incubator Group"
-    },
-    "UMA": {
-        "authors": [
-            "Eve Maler",
-            "Maciej Machulak",
-            "Justin Richer"
-        ],
-        "href": "https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html",
-        "title": "User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization",
-        "publisher": "Kantara Initiative, Inc"
-    },
-    "BCP195": {
-        "href": "https://www.rfc-editor.org/info/bcp195",
-        "title": "Best Current Practice 195",
-        "publisher": "IETF"
-    }
-}
-
+ +# Privacy Considerations # {#privacy} + +## OIDC ID Token Reuse ## {#privacy-token-reuse} + +*This section is non-normative* + +With JWTs being extendable by design, there is potential for a privacy breach if OIDC ID Tokens get +reused across multiple authorization servers. It is not unimaginable that a custom claim is added to the +OIDC ID Token on instantiation. This addition may unintentionally give other authorization servers +consuming the OIDC ID Token information about the user that they may not wish to share outside of the +intended AS. + +# Acknowledgments # {#acknowledgments} + +*This section is non-normative* + +The Solid Community Group would like to thank the following individuals for reviewing and providing +feedback on the specification (in alphabetical order): + +Tim Berners-Lee, Justin Bingham, Sarven Capadisli, Aaron Coburn, Matthias Evering, Jamie Fiedler, +Michiel de Jong, Ted Thibodeau Jr, Kjetil Kjernsmo, Mitzi László, Pat McBennett, Adam Migus, Jackson Morgan, Davi +Ottenheimer, Justin Richer, severin-dsr, Henry Story, Michael Thornburgh, Emmet Townsend, Ruben +Verborgh, Ricky White, Paul Worrall, Dmitri Zagidulin. + +# Appendix A: Full JSON-LD context # {#full-jsonld-context} + +The JSON-LD context is defined as: + +
+  {
+    "@context": {
+      "@version": 1.1,
+      "@protected": true,
+      "oidc": "http://www.w3.org/ns/solid/oidc#",
+      "xsd": "http://www.w3.org/2001/XMLSchema#",
+      "client_id": {
+        "@id": "@id",
+        "@type": "@id"
+      },
+      "client_uri": {
+        "@id": "oidc:client_uri",
+        "@type": "@id"
+      },
+      "logo_uri": {
+        "@id": "oidc:logo_uri",
+        "@type": "@id"
+      },
+      "policy_uri": {
+        "@id": "oidc:policy_uri",
+        "@type": "@id"
+      },
+      "tos_uri": {
+        "@id": "oidc:tos_uri",
+        "@type": "@id"
+      },
+      "redirect_uris": {
+        "@id": "oidc:redirect_uris",
+        "@type": "@id",
+        "@container": [
+          "@id",
+          "@set"
+        ]
+      },
+      "require_auth_time": {
+        "@id": "oidc:require_auth_time",
+        "@type": "xsd:boolean"
+      },
+      "default_max_age": {
+        "@id": "oidc:default_max_age",
+        "@type": "xsd:integer"
+      },
+      "application_type": {
+        "@id": "oidc:application_type"
+      },
+      "client_name": {
+        "@id": "oidc:client_name"
+      },
+      "contacts": {
+        "@id": "oidc:contacts"
+      },
+      "grant_types": {
+        "@id": "oidc:grant_types"
+      },
+      "response_types": {
+        "@id": "oidc:response_types"
+      },
+      "scope": {
+        "@id": "oidc:scope"
+      },
+      "token_endpoint_auth_method": {
+        "@id": "oidc:token_endpoint_auth_method"
+      }
+    }
+  }
+
+ +
+{
+    "DPOP": {
+        "authors": [
+            "D. Fett",
+            "B. Campbell",
+            "J. Bradley",
+            "T. Lodderstedt",
+            "M. Jones",
+            "D. Waite"
+        ],
+        "href": "https://tools.ietf.org/html/draft-ietf-oauth-dpop",
+        "title": "OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer (DPoP)",
+        "publisher": "IETF"
+    },
+    "OIDC-CORE": {
+        "authors": [
+            "N. Sakimura",
+            "J. Bradley",
+            "M. Jones",
+            "B. de Medeiros",
+            "C. Mortimore"
+        ],
+        "href": "https://openid.net/specs/openid-connect-core-1_0.html",
+        "title": "OpenID Connect Core 1.0",
+        "publisher": "The OpenID Foundation"
+    },
+    "OIDC-DISCOVERY": {
+        "authors": [
+            "N. Sakimura",
+            "J. Bradley",
+            "M. Jones",
+            "E. Jay"
+        ],
+        "href": "https://openid.net/specs/openid-connect-discovery-1_0.html",
+        "title": "OpenID Connect Discovery 1.0",
+        "publisher": "The OpenID Foundation"
+    },
+    "OIDC-DYNAMIC-CLIENT-REGISTRATION": {
+        "authors": [
+            "N. Sakimura",
+            "J. Bradley",
+            "M.B. Jones"
+        ],
+        "href": "https://openid.net/specs/openid-connect-registration-1_0.html",
+        "title": "OpenID Connect Dynamic Client Registration 1.0",
+        "publisher": "The OpenID Foundation"
+    },
+    "SOLID-PROTOCOL": {
+        "authors": [
+            "Sarven Capadisli",
+            "Tim Berners-Lee",
+            "Ruben Verborgh",
+            "Kjetil Kjernsmo",
+            "Justin Bingham",
+            "Dmitri Zagidulin"
+        ],
+        "href": "https://solidproject.org/TR/protocol",
+        "title": "Solid Protocol",
+        "publisher": "W3C Solid Community Group"
+    },
+    "SOLID-OIDC-PRIMER": {
+        "authors": [
+            "Jackson Morgan",
+            "Aaron Coburn",
+            "Matthieu Bosquet"
+        ],
+        "href": "https://solid.github.io/solid-oidc/primer/",
+        "title": "Solid-OIDC Primer",
+        "publisher": "W3C Solid Community Group"
+    },
+    "WEBID": {
+        "authors": [
+            "Andrei Sambra",
+            "Henry Story",
+            "Tim Berners-Lee"
+        ],
+        "href": "https://www.w3.org/2005/Incubator/webid/spec/identity/",
+        "title": "WebID 1.0",
+        "publisher": "WebID Incubator Group"
+    },
+    "UMA": {
+        "authors": [
+            "Eve Maler",
+            "Maciej Machulak",
+            "Justin Richer"
+        ],
+        "href": "https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html",
+        "title": "User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization",
+        "publisher": "Kantara Initiative, Inc"
+    },
+    "BCP195": {
+        "href": "https://www.rfc-editor.org/info/bcp195",
+        "title": "Best Current Practice 195",
+        "publisher": "IETF"
+    }
+}
+
From 717392dfeb96048bc8740e6f9b8d5e8215387c97 Mon Sep 17 00:00:00 2001 From: Christoph Braun Date: Thu, 18 Jun 2026 18:10:16 +0200 Subject: [PATCH 4/5] merge main into feat/security-issuer-trust --- index.bs | 1470 ++++++++++++++++++++++++----------------------- primer/index.bs | 15 +- setup.sh | 10 +- 3 files changed, 752 insertions(+), 743 deletions(-) diff --git a/index.bs b/index.bs index 31199cb..8ee103f 100644 --- a/index.bs +++ b/index.bs @@ -1,734 +1,736 @@ -
-Title: Solid-OIDC
-Boilerplate: issues-index no
-Shortname: solid-oidc
-Level: 1
-Status: CG-DRAFT
-Group: solidcg
-ED: https://solid.github.io/solid-oidc/
-TR: https://solidproject.org/TR/oidc
-!Created: July 16, 2021
-!Modified: [DATE]
-Repository: https://github.com/solid/solid-oidc
-Inline Github Issues: title
-Markup Shorthands: markdown yes
-Max ToC Depth: 2
-Editor: [Aaron Coburn](https://people.apache.org/~acoburn/#i) ([Inrupt](https://inrupt.com))
-Editor: [elf Pavlik](https://elf-pavlik.hackers4peace.net)
-Editor: Christoph Braun (Forschungszentrum Informatik (FZI))
-Former Editor: [Dmitri Zagidulin](http://computingjoy.com/)
-Former Editor: [Adam Migus](https://migusgroup.com/about/) ([The Migus Group](https://migusgroup.com/))
-Former Editor: [Ricky White](https://rickywhite.net) ([The Migus Group](https://migusgroup.com/))
-Test Suite: https://solid-contrib.github.io/solid-oidc-tests/
-Metadata Order: This version, Latest published version, Test Suite, Created, Modified, *, !*
-Abstract:
-  The Solid OpenID Connect (Solid-OIDC) specification defines how resource servers
-  verify the identity of relying parties and end users based on the authentication
-  performed by an OpenID provider. Solid-OIDC builds on top of OpenID Connect 1.0
-  for use within the Solid ecosystem.
-
- -# Introduction # {#intro} - -*This section is non-normative* - -The [Solid project](https://solidproject.org/) aims to change the way web applications work today to -improve privacy and user control of personal data by utilizing current standards, protocols, and -tools, to facilitate building extensible and modular decentralized applications based on -[Linked Data](https://www.w3.org/standards/semanticweb/data) principles. - -This specification is written for Authorization and Resource Server owners intending to implement -Solid-OIDC. It is also useful to Solid application developers charged with implementing a Solid-OIDC -client. - -The OAuth 2.0 [[!RFC6749]] and OpenID Connect Core 1.0 [[!OIDC-CORE]] web standards were -published in October 2012 and November 2014, respectively. Since publication they've seen rapid and -widespread adoption across the industry, in turn gaining extensive *"real-world"* data and -experience. The strengths of the protocols are now clear; however, in a changing eco-system where -privacy and control of digital identities are becoming more pressing concerns, it is also clear -that additional functionality is required. - -The additional functionality documented herein aims to address: - -1. Resource servers and their Authorization servers having no existing trust relationship with identity providers. -2. Ephemeral Clients as a first-order use-case. - -## Out of Scope ## {#intro-out-of-scope} - -*This section is non-normative* - -While the Solid-OIDC specification describes the structure of an ID Token for use in Solid, the definition of a global access token for use with Solid Resource Servers is beyond the scope of this specification. - -# Terminology # {#terms} - -*This section is non-normative* - -This specification uses the terms "access token", "authorization server", "resource server" (RS), "token endpoint", -"grant type", and "client" as defined by The OAuth 2.0 Authorization Framework [[!RFC6749]]. - -Throughout this specification, we will use the term OpenID Provider (OP) in line with the -terminology used in the Open ID Connect Core 1.0 specification (OIDC) [[!OIDC-CORE]]. -It should be noted that this is distinct from the entity referred to as an Authorization Server -by the OAuth 2.0 Authorization Framework (OAuth) [[!RFC6749]]. - -This specification also uses the following terms: - -
-
*WebID* as defined by [[!WEBID]] -
- A WebID is a URI with an HTTP or HTTPS scheme which denotes an Agent (Person, Organization, Group, - Device, etc.). - -
*JSON Web Token (JWT)* as defined by [[!RFC7519]] -
- A string representing a set of claims as a JSON object that is encoded in a JWS or JWE, enabling the - claims to be digitally signed or MACed and/or encrypted. - -
*JSON Web Key (JWK)* as defined by [[!RFC7517]] -
- A JSON object that represents a cryptographic key. The members of the object represent properties of - the key, including its value. - -
*Demonstration of Proof-of-Possession at the Application Layer (DPoP)* as defined by [[!DPOP]] -
- A mechanism for sender-constraining OAuth tokens via a proof-of-possession mechanism on the - application level. - -
*DPoP Proof* as defined by [[!DPOP]] -
- A DPoP proof is a JWT that is signed (using JWS) using a private key chosen by the client. - -
*Proof Key for Code Exchange (PKCE)* as defined by [[!RFC7636]] -
- An extension to the Authorization Code flow which mitigates the risk of an authorization code - interception attack. -
- -# Core Concepts # {#concepts} - -*This section is non-normative* - -In a decentralized ecosystem, such as Solid, an OP may be an identity-as-a-service vendor or, at -the other end of the spectrum, a user-controlled OP. In either case, the user may be authenticating -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 -preexisting trust relationships with the OP. This means that client registration, whether dynamic, -or static, is entirely optional. - -## WebIDs ## {#concepts-webids} - -*This section is non-normative* - -In line with Linked Data principles, a WebID is a HTTP URI that, -when dereferenced, resolves to a profile document that is structured data in an -[RDF 1.1 format](https://www.w3.org/TR/rdf11-concepts/). This profile document allows -people to link with others to grant access to identity resources as they see fit. WebIDs underpin -Solid and are used as a primary identifier for Users in this specification. - -# Basic Flow # {#basic-flow} - -*This section is non-normative* - -Details of the flow are available in [[!SOLID-OIDC-PRIMER]] - -
- -
Basic sequence of authenticating the user and the client.
-
- -# Client Identifiers # {#clientids} - -OAuth and OIDC require the Client application to identify itself to the OP and RS by presenting a -[client identifier](https://tools.ietf.org/html/rfc6749#section-2.2) (Client ID). Solid applications -SHOULD use a URI that can be dereferenced as a [Client ID Document](#clientids-document). - -Issue(78): - -## Client ID Document ## {#clientids-document} - -When a Client Identifier is dereferenced, the resource MUST be serialized as an `application/ld+json` document -unless content negotiation requires a different outcome. - -The serialized JSON form of a Client ID Document MUST use the normative JSON-LD `@context` -provided at `https://www.w3.org/ns/solid/oidc-context.jsonld` such that the resulting -document produces a JSON serialization of an OIDC client registration, per the -definition of client registration metadata from [[!RFC7591]] section 2. - -Also, the OP MUST dereference the Client ID Document and match any Client-supplied parameters -with the values in the Client ID Document. - -Further, the `redirect_uri` provided by the Client MUST be included in the registration `redirect_uris` -list. - -This example uses [JSON-LD ](https://www.w3.org/TR/json-ld/) for the Client ID Document: - -
-

https://app.example/id

- - 
-        {
-          "@context": ["https://www.w3.org/ns/solid/oidc-context.jsonld"],
-
-          "client_id": "https://app.example/id",
-          "client_name": "Solid Application Name",
-          "redirect_uris": ["https://app.example/callback"],
-          "post_logout_redirect_uris": ["https://app.example/logout"],
-          "client_uri": "https://app.example/",
-          "logo_uri" : "https://app.example/logo.png",
-          "tos_uri" : "https://app.example/tos.html",
-          "scope" : "openid profile offline_access webid",
-          "grant_types" : ["refresh_token","authorization_code"],
-          "response_types" : ["code"],
-          "default_max_age" : 3600,
-          "require_auth_time" : true
-        }
-
-
- -Issue(95): - -### JSON-LD context ### {#jsonld-context} - -This specification defines a JSON-LD context for use with OIDC Client ID Documents. This context is -available at `https://www.w3.org/ns/solid/oidc-context.jsonld`. Client ID Documents that reference -this JSON-LD context MUST use the HTTPS scheme. - -NOTE: the [Solid-OIDC Vocabulary](https://www.w3.org/ns/solid/oidc) that is part of this context uses the HTTP scheme. - -Full content of JSON-LD context can be also seen in [[#full-jsonld-context]] - -## OIDC Registration ## {#clientids-oidc} - -For non-dereferencable identifiers, the Client MUST present a `client_id` value that has been -registered with the OP via either OIDC dynamic or static registration. -See also [[!OIDC-DYNAMIC-CLIENT-REGISTRATION]]. - -When requesting Dynamic Client Registration, the Client MUST specify the `scope` in the metadata -and include `webid` in its value (space-separated list). - -
- 
-        {
-          "client_name": "S-C-A Browser Demo Client App",
-          "application_type": "web",
-          "redirect_uris": [
-            "https://dynamic-client.example/auth"
-          ],
-          "subject_type": "pairwise",
-          "token_endpoint_auth_method": "client_secret_basic",
-          "scope" : "openid profile offline_access webid"
-        }
-
-
- -# WebID Profile # {#webid-profile} - -Dereferencing the WebID URL results in a WebID Profile. - -Issue(76): - -## OIDC Issuer Discovery ## {#oidc-issuer-discovery} - -A WebID Profile lists the OpenID Providers who are trusted to issue tokens on behalf -of the agent who controls the WebID. This prevents a malicious OpenID Provider from issuing -otherwise valid ID Tokens for arbitrary WebIDs. An entity that verifies ID Tokens will use this -mechanism to determine if the issuer is authoritative for the given WebID. - -
- 
-      PREFIX solid: <http://www.w3.org/ns/solid/terms#>
-
-      <#id> solid:oidcIssuer <https://oidc.example> .
-
-
WebID Profile specifying an OIDC issuer
-
- -To discover a list of valid issuers, the WebID Profile MUST be checked for the existence of statements matching -
-  ?webid <http://www.w3.org/ns/solid/terms#oidcIssuer> ?iss .
-
-where `?webid` is set to WebID. The `?iss` will result in an IRI denoting valid issuer for that WebID. -The WebID Profile Document MUST include one or more statements matching the OIDC issuer pattern. - -Issue(80): - -Issue(92): - -Issue(91): - -### OIDC Issuer Discovery via Link Headers ### {#oidc-issuer-discovery-link-headers} - -A server hosting a WebID Profile Document MAY transmit the `http://www.w3.org/ns/solid/terms#oidcIssuer` -values via Link Headers, but they MUST be the same as in the RDF representation. -A client MUST treat the RDF in the body of the WebID Profile as canonical -but MAY use the Link Header values as an optimization. - -
- 
-        Link: <https://oidc.example>;
-              rel="http://www.w3.org/ns/solid/terms#oidcIssuer";
-              anchor="#id"
-
-
HTTP response Link Header (line breaks added for readibility)
-
- - -# Requesting the WebID Claim using a Scope Value # {#webid-scope} - -Solid-OIDC uses scope values, as defined in [[!RFC6749]] Section 3.3 and [[!OIDC-CORE]] Section 5.4 to specify -what information is made available as Claim Values. - -Solid-OIDC defines the following `scope` value for use with claim requests: - -
-
*webid* -
- REQUIRED. This scope requests access to the End-User's `webid` Claim. -
- - -# 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. -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. -The value of the `iss` parameter MUST be the Issuer Identifier of the OP, as defined in [[OIDC-CORE]]. -
- 
-HTTP/1.1 302 Found
-Location: https://client.example.com/callback?
-                                        code=n0esc392ae491076
-                                        &state=af0ifjsldkj
-                                        &iss=https%3A%2F%2Fidp.example.com
-
-
Example Authorization Response including the `iss` query parameter
-
- -Upon receiving the authorization response, the Client MUST validate the `iss` parameter: -* The Client MUST check for the presence of the `iss` parameter. -* The Client MUST verify that the `iss` value matches the Issuer Identifier of the OP to which the authorization request was sent. - -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. - - -# Token Instantiation # {#tokens} - -Assuming one of the following options - - 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. - -## DPoP-bound OIDC ID Token ## {#tokens-id} - -When requesting a DPoP-bound OIDC ID Token, the Client MUST send a DPoP proof JWT -that is valid according to the [[DPOP#section-5]]. The DPoP proof JWT is used to -bind the OIDC ID Token to a public key. See also: [[!DPOP]]. - -With the `webid` scope, the DPoP-bound OIDC ID Token payload MUST contain these claims: - * `webid` — The WebID claim MUST be the user's WebID. - * `iss` — The issuer claim MUST be a valid URL of the OP - instantiating this token. - * `aud` — The audience claim MUST be an array of values. - The values MUST include the authorized party claim `azp` - and the string `solid`. - In the decentralized world - of Solid-OIDC, the audience of an ID Token is not only the client (`azp`), - but also any Solid Authorization Server at any accessible address - on the world wide web (`solid`). See also: [[RFC7519#section-4.1.3]]. - * `azp` - The authorized party claim is used to identify the client - (See also: [section 5. Client Identifiers](#clientids)). - * `iat` — The issued-at claim is the time at which the DPoP-bound - OIDC ID Token was issued. - * `exp` — The expiration claim is the time at which the DPoP-bound - OIDC ID Token becomes invalid. - * `cnf` — The confirmation claim is used to identify the DPoP Public - Key bound to the OIDC ID Token. See also: [[DPOP#section-7]]. - -
-

An example OIDC ID Token: - - 

-        {
-            "webid": "https://janedoe.com/web#id",
-            "iss": "https://idp.example.com",
-            "sub": "janedoe",
-            "aud": ["https://client.example.com/client_id", "solid"],
-            "azp": "https://client.example.com/client_id",
-            "iat": 1311280970,
-            "exp": 1311281970,
-            "cnf":{
-              "jkt":"0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I"
-            }
-        }
-
-
- -Issue(26): - -Issue(47): - -### ID Token Validation ### {#id-token-validation} - -An ID Token must be validated according to [OIDC-CORE, Section 3.1.3.7](https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation) - -The Verifying party MUST perform [[#oidc-issuer-discovery]] using the value of the `webid` claim -to dereference the WebID Profile Document. - -Unless the verifying party acquires OP keys through some other means, or it chooses to reject tokens issued by this OP, -the verifying party MUST follow OpenID Connect Discovery 1.0 [[!OIDC-DISCOVERY]] to find an OP's signing keys (JWK). - -# Resource Access # {#resource} - -## Authorization Server Discovery ## {#authorization-server-discovery} - -When a Client performs an unauthenticated request to a protected resource, -the Resource Server MUST respond with the HTTP 401 status code, -and a WWW-Authenticate HTTP header. See also: [[RFC9110]](11.6.1. WWW-Authenticate) - -The WWW-Authenticate HTTP header MUST include an as_uri -parameter unless the authentication scheme requires a different mechanism -for discovering an associated authorization server. - -Authorization Servers SHOULD implement User-Managed Access (UMA) 2.0 Grant for -OAuth 2.0 Authorization [[!UMA]]. - -## Obtaining an Access Token ## {#obtaining-access-token} - -For Authorization Servers that conform to [[!UMA]], the -http://openid.net/specs/openid-connect-core-1_0.html#IDToken profile MUST -be supported. This profile MUST be advertised in the uma_profiles_supported -metadata of the Authorization Server discovery document [[UMA#rfc.section.2]]. - -When using the http://openid.net/specs/openid-connect-core-1_0.html#IDToken -profile with an UMA-based Authorization Server, the Authorization Server MUST be capable -of exchanging a valid Solid-OIDC ID Token [[#tokens-id]] for an OAuth 2.0 Access Token. - -Note: Clients can push additional claims by requesting an upgraded RPT [[UMA#rfc.section.3.3.1]] - -Authorization Server MUST pefrom [[#dpop-validation]] and [[#id-token-validation]] - -## DPoP Validation ## {#dpop-validation} - -A DPoP Proof that is valid according to -[DPoP Internet-Draft, Section 4.3](https://tools.ietf.org/html/draft-ietf-oauth-dpop-04#section-4.3), -MUST be present when a DPoP-bound OIDC ID Token is used. - -The DPoP-bound OIDC ID Token MUST be validated according to -[DPoP Internet-Draft, Section 6](https://tools.ietf.org/html/draft-ietf-oauth-dpop-04#section-6), -but the AS MAY perform additional verification in order to determine whether to grant access to the -requested resource. - -# Solid-OIDC Conformance Discovery # {#discovery} - -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. - -
- 
-        {
-            "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 SHOULD 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](https://www.rfc-editor.org/rfc/rfc6749#section-1.5), when supported by the server. - -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* - -
- When using the Client Credentials Grant, a Client could authenticate with the OP using a `client_id` - 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. -
- -NOTE: [[!RFC7523]] (Section 2.2) presents another way to handle authentication using JWTs. - -## 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's authentication -credentials. - -## Solid-OIDC Conformance Discovery ## {#client-credentials-discovery} - -For non-interactive use cases such as scripts, automated agents, and server-to-server communication, an OpenID Provider -that supports the [Client Credentials Grant](https://www.rfc-editor.org/rfc/rfc6749#section-4.4) MUST advertise that -support in the OpenID Connect Discovery 1.0 [OIDC.Discovery] resource by including `client_credentials` in its -`grant_types_supported` metadata property. - -
- 
-        {
-            "grant_types_supported": ["authorization_code", "refresh_token", "client_credentials"]
-        }
-
-
- -# Security Considerations # {#security} - -*This section is non-normative* - -As this specification builds upon existing web standards, security considerations from OAuth, OIDC, -PKCE, and the DPoP specifications may also apply unless otherwise indicated. The following -considerations should be reviewed by implementors and system/s architects of this specification. - -Some of the references within this specification point to documents with a -Living Standard or Draft status, meaning their contents can still change over -time. It is advised to monitor these documents, as such changes might have -security implications. - -In addition to above considerations, implementors should consider the Security -Considerations in context of the Solid Protocol [[!SOLID-PROTOCOL]]. - -## TLS Requirements ## {#security-tls} - -All TLS requirements outlined in [[BCP195]] apply to this -specification. - -All tokens, Client, and User credentials MUST only be transmitted over TLS. - -## Client IDs ## {#security-client-ids} - -An AS SHOULD assign a fixed set of low trust policies to any client identified as anonymous. - -Implementors SHOULD expire ephemeral Client IDs that are kept in server storage to mitigate the -potential for a bad actor to fill server storage with unexpired or otherwise useless Client IDs. - -## Client Secrets ## {#security-client-secrets} - -Client secrets SHOULD NOT be stored in browser local storage. Doing so will increase the risk of -data leaks should an attacker gain access to Client credentials. - -## Client Trust ## {#security-client-trust} - -*This section is non-normative* - -Clients are ephemeral, client registration is optional, and most Clients cannot keep secrets. These, -among other factors, are what makes Client trust challenging. - -## Issuer Trust ## {#security-issuer-trust} - -*This section is non-normative* - -A Solid-OIDC user's identity is asserted by the OpenID Provider listed in their WebID Profile via -`solid:oidcIssuer`. Implementers and end-users should consider the trust they place in that issuer: - -* **User trusts identity provider to be honest.** The user's chosen identity provider is able to assert the identity of the user in an issued identity token. The user relies on the identity provider to obtain such identity token and trusts the identity provider not to issue such token of the user's identity to a different user or to use that token themselves. A compromised or malicious identity provider is able to let other malicious agents impersonate the user or to impersonate the user themself. If the user's identity provider is unavailable, the user is unable to obtain an identity token, which might lead the user to be unable to access data that requires authentication and thereby implicitly denying access to data. A high degree of trust in the chosen identity provider is therefore necessary. -The authorization server has to choose to trust the identity provider selected by the user before granting access. This choice may be to delegate the choice completely to users, or to restrict the set of identity providers to a specific trust list. -* **Identity Provider as a Single Point of Failure.** When an agent has only one identity provider, only that single identity provider is able to assert the identity of the agent. In case this identity provider is unavailable, the agent is unable to authenticate itself. -Agents may have multiple identity providers. Having multiple identity providers can provide redundancy in the event of an outage of one identity provider service. The trade-off is that this increases the attack surface of malicious identity providers. -Where many agents share a single identity provider, that identity provider is a concentration point: a single compromise, outage, or service-level decision affects every agent that depends on it. Attacks tend to focus on major centralization, so concentration risk grows with the issuer's user base. Implementations offering accounts under a shared issuer should plan for this risk. - -# Privacy Considerations # {#privacy} - -## OIDC ID Token Reuse ## {#privacy-token-reuse} - -*This section is non-normative* - -With JWTs being extendable by design, there is potential for a privacy breach if OIDC ID Tokens get -reused across multiple authorization servers. It is not unimaginable that a custom claim is added to the -OIDC ID Token on instantiation. This addition may unintentionally give other authorization servers -consuming the OIDC ID Token information about the user that they may not wish to share outside of the -intended AS. - -# Acknowledgments # {#acknowledgments} - -*This section is non-normative* - -The Solid Community Group would like to thank the following individuals for reviewing and providing -feedback on the specification (in alphabetical order): - -Tim Berners-Lee, Justin Bingham, Sarven Capadisli, Aaron Coburn, Matthias Evering, Jamie Fiedler, -Michiel de Jong, Ted Thibodeau Jr, Kjetil Kjernsmo, Mitzi László, Pat McBennett, Adam Migus, Jackson Morgan, Davi -Ottenheimer, Justin Richer, severin-dsr, Henry Story, Michael Thornburgh, Emmet Townsend, Ruben -Verborgh, Ricky White, Paul Worrall, Dmitri Zagidulin. - -# Appendix A: Full JSON-LD context # {#full-jsonld-context} - -The JSON-LD context is defined as: - -
-  {
-    "@context": {
-      "@version": 1.1,
-      "@protected": true,
-      "oidc": "http://www.w3.org/ns/solid/oidc#",
-      "xsd": "http://www.w3.org/2001/XMLSchema#",
-      "client_id": {
-        "@id": "@id",
-        "@type": "@id"
-      },
-      "client_uri": {
-        "@id": "oidc:client_uri",
-        "@type": "@id"
-      },
-      "logo_uri": {
-        "@id": "oidc:logo_uri",
-        "@type": "@id"
-      },
-      "policy_uri": {
-        "@id": "oidc:policy_uri",
-        "@type": "@id"
-      },
-      "tos_uri": {
-        "@id": "oidc:tos_uri",
-        "@type": "@id"
-      },
-      "redirect_uris": {
-        "@id": "oidc:redirect_uris",
-        "@type": "@id",
-        "@container": [
-          "@id",
-          "@set"
-        ]
-      },
-      "require_auth_time": {
-        "@id": "oidc:require_auth_time",
-        "@type": "xsd:boolean"
-      },
-      "default_max_age": {
-        "@id": "oidc:default_max_age",
-        "@type": "xsd:integer"
-      },
-      "application_type": {
-        "@id": "oidc:application_type"
-      },
-      "client_name": {
-        "@id": "oidc:client_name"
-      },
-      "contacts": {
-        "@id": "oidc:contacts"
-      },
-      "grant_types": {
-        "@id": "oidc:grant_types"
-      },
-      "response_types": {
-        "@id": "oidc:response_types"
-      },
-      "scope": {
-        "@id": "oidc:scope"
-      },
-      "token_endpoint_auth_method": {
-        "@id": "oidc:token_endpoint_auth_method"
-      }
-    }
-  }
-
- -
-{
-    "DPOP": {
-        "authors": [
-            "D. Fett",
-            "B. Campbell",
-            "J. Bradley",
-            "T. Lodderstedt",
-            "M. Jones",
-            "D. Waite"
-        ],
-        "href": "https://tools.ietf.org/html/draft-ietf-oauth-dpop",
-        "title": "OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer (DPoP)",
-        "publisher": "IETF"
-    },
-    "OIDC-CORE": {
-        "authors": [
-            "N. Sakimura",
-            "J. Bradley",
-            "M. Jones",
-            "B. de Medeiros",
-            "C. Mortimore"
-        ],
-        "href": "https://openid.net/specs/openid-connect-core-1_0.html",
-        "title": "OpenID Connect Core 1.0",
-        "publisher": "The OpenID Foundation"
-    },
-    "OIDC-DISCOVERY": {
-        "authors": [
-            "N. Sakimura",
-            "J. Bradley",
-            "M. Jones",
-            "E. Jay"
-        ],
-        "href": "https://openid.net/specs/openid-connect-discovery-1_0.html",
-        "title": "OpenID Connect Discovery 1.0",
-        "publisher": "The OpenID Foundation"
-    },
-    "OIDC-DYNAMIC-CLIENT-REGISTRATION": {
-        "authors": [
-            "N. Sakimura",
-            "J. Bradley",
-            "M.B. Jones"
-        ],
-        "href": "https://openid.net/specs/openid-connect-registration-1_0.html",
-        "title": "OpenID Connect Dynamic Client Registration 1.0",
-        "publisher": "The OpenID Foundation"
-    },
-    "SOLID-PROTOCOL": {
-        "authors": [
-            "Sarven Capadisli",
-            "Tim Berners-Lee",
-            "Ruben Verborgh",
-            "Kjetil Kjernsmo",
-            "Justin Bingham",
-            "Dmitri Zagidulin"
-        ],
-        "href": "https://solidproject.org/TR/protocol",
-        "title": "Solid Protocol",
-        "publisher": "W3C Solid Community Group"
-    },
-    "SOLID-OIDC-PRIMER": {
-        "authors": [
-            "Jackson Morgan",
-            "Aaron Coburn",
-            "Matthieu Bosquet"
-        ],
-        "href": "https://solid.github.io/solid-oidc/primer/",
-        "title": "Solid-OIDC Primer",
-        "publisher": "W3C Solid Community Group"
-    },
-    "WEBID": {
-        "authors": [
-            "Andrei Sambra",
-            "Henry Story",
-            "Tim Berners-Lee"
-        ],
-        "href": "https://www.w3.org/2005/Incubator/webid/spec/identity/",
-        "title": "WebID 1.0",
-        "publisher": "WebID Incubator Group"
-    },
-    "UMA": {
-        "authors": [
-            "Eve Maler",
-            "Maciej Machulak",
-            "Justin Richer"
-        ],
-        "href": "https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html",
-        "title": "User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization",
-        "publisher": "Kantara Initiative, Inc"
-    },
-    "BCP195": {
-        "href": "https://www.rfc-editor.org/info/bcp195",
-        "title": "Best Current Practice 195",
-        "publisher": "IETF"
-    }
-}
-
+
+Title: Solid-OIDC
+Boilerplate: issues-index no
+Shortname: solid-oidc
+Level: 1
+Org: W3C
+Group: solidcg
+Status: CG-DRAFT
+ED: https://solid.github.io/solid-oidc/
+TR: https://solidproject.org/TR/oidc
+!Created: July 16, 2021
+!Modified: [DATE]
+Repository: https://github.com/solid/solid-oidc
+Inline Github Issues: title
+Markup Shorthands: markdown yes
+Max ToC Depth: 2
+Editor: Aaron Coburn, Inrupt https://inrupt.com, https://github.com/acoburn
+Editor: elf Pavlik, https://elf-pavlik.hackers4peace.net
+Editor: Christoph Braun, Forschungszentrum Informatik (FZI) https://www.fzi.de, https://github.com/uvdsl
+Former Editor: Dmitri Zagidulin, http://computingjoy.com/
+Former Editor: Adam Migus, The Migus Group https://migusgroup.com, https://migusgroup.com/about/
+Former Editor: Ricky White, The Migus Group https://migusgroup.com/, https://rickywhite.net
+Test Suite: https://solid-contrib.github.io/solid-oidc-tests/
+Metadata Order: This version, Latest published version, Test Suite, Created, Modified, *, !*
+Abstract:
+  The Solid OpenID Connect (Solid-OIDC) specification defines how resource servers
+  verify the identity of relying parties and end users based on the authentication
+  performed by an OpenID provider. Solid-OIDC builds on top of OpenID Connect 1.0
+  for use within the Solid ecosystem.
+
+ +# Introduction # {#intro} + +*This section is non-normative* + +The [Solid project](https://solidproject.org/) aims to change the way web applications work today to +improve privacy and user control of personal data by utilizing current standards, protocols, and +tools, to facilitate building extensible and modular decentralized applications based on +[Linked Data](https://www.w3.org/standards/semanticweb/data) principles. + +This specification is written for Authorization and Resource Server owners intending to implement +Solid-OIDC. It is also useful to Solid application developers charged with implementing a Solid-OIDC +client. + +The OAuth 2.0 [[!RFC6749]] and OpenID Connect Core 1.0 [[!OIDC-CORE]] web standards were +published in October 2012 and November 2014, respectively. Since publication they've seen rapid and +widespread adoption across the industry, in turn gaining extensive *"real-world"* data and +experience. The strengths of the protocols are now clear; however, in a changing eco-system where +privacy and control of digital identities are becoming more pressing concerns, it is also clear +that additional functionality is required. + +The additional functionality documented herein aims to address: + +1. Resource servers and their Authorization servers having no existing trust relationship with identity providers. +2. Ephemeral Clients as a first-order use-case. + +## Out of Scope ## {#intro-out-of-scope} + +*This section is non-normative* + +While the Solid-OIDC specification describes the structure of an ID Token for use in Solid, the definition of a global access token for use with Solid Resource Servers is beyond the scope of this specification. + +# Terminology # {#terms} + +*This section is non-normative* + +This specification uses the terms "access token", "authorization server", "resource server" (RS), "token endpoint", +"grant type", and "client" as defined by The OAuth 2.0 Authorization Framework [[!RFC6749]]. + +Throughout this specification, we will use the term OpenID Provider (OP) in line with the +terminology used in the Open ID Connect Core 1.0 specification (OIDC) [[!OIDC-CORE]]. +It should be noted that this is distinct from the entity referred to as an Authorization Server +by the OAuth 2.0 Authorization Framework (OAuth) [[!RFC6749]]. + +This specification also uses the following terms: + +
+
*WebID* as defined by [[!WEBID]] +
+ A WebID is a URI with an HTTP or HTTPS scheme which denotes an Agent (Person, Organization, Group, + Device, etc.). + +
*JSON Web Token (JWT)* as defined by [[!RFC7519]] +
+ A string representing a set of claims as a JSON object that is encoded in a JWS or JWE, enabling the + claims to be digitally signed or MACed and/or encrypted. + +
*JSON Web Key (JWK)* as defined by [[!RFC7517]] +
+ A JSON object that represents a cryptographic key. The members of the object represent properties of + the key, including its value. + +
*Demonstration of Proof-of-Possession at the Application Layer (DPoP)* as defined by [[!DPOP]] +
+ A mechanism for sender-constraining OAuth tokens via a proof-of-possession mechanism on the + application level. + +
*DPoP Proof* as defined by [[!DPOP]] +
+ A DPoP proof is a JWT that is signed (using JWS) using a private key chosen by the client. + +
*Proof Key for Code Exchange (PKCE)* as defined by [[!RFC7636]] +
+ An extension to the Authorization Code flow which mitigates the risk of an authorization code + interception attack. +
+ +# Core Concepts # {#concepts} + +*This section is non-normative* + +In a decentralized ecosystem, such as Solid, an OP may be an identity-as-a-service vendor or, at +the other end of the spectrum, a user-controlled OP. In either case, the user may be authenticating +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 +preexisting trust relationships with the OP. This means that client registration, whether dynamic, +or static, is entirely optional. + +## WebIDs ## {#concepts-webids} + +*This section is non-normative* + +In line with Linked Data principles, a WebID is a HTTP URI that, +when dereferenced, resolves to a profile document that is structured data in an +[RDF 1.1 format](https://www.w3.org/TR/rdf11-concepts/). This profile document allows +people to link with others to grant access to identity resources as they see fit. WebIDs underpin +Solid and are used as a primary identifier for Users in this specification. + +# Basic Flow # {#basic-flow} + +*This section is non-normative* + +Details of the flow are available in [[!SOLID-OIDC-PRIMER]] + +
+ +
Basic sequence of authenticating the user and the client.
+
+ +# Client Identifiers # {#clientids} + +OAuth and OIDC require the Client application to identify itself to the OP and RS by presenting a +[client identifier](https://tools.ietf.org/html/rfc6749#section-2.2) (Client ID). Solid applications +SHOULD use a URI that can be dereferenced as a [Client ID Document](#clientids-document). + +Issue(78): + +## Client ID Document ## {#clientids-document} + +When a Client Identifier is dereferenced, the resource MUST be serialized as an `application/ld+json` document +unless content negotiation requires a different outcome. + +The serialized JSON form of a Client ID Document MUST use the normative JSON-LD `@context` +provided at `https://www.w3.org/ns/solid/oidc-context.jsonld` such that the resulting +document produces a JSON serialization of an OIDC client registration, per the +definition of client registration metadata from [[!RFC7591]] section 2. + +Also, the OP MUST dereference the Client ID Document and match any Client-supplied parameters +with the values in the Client ID Document. + +Further, the `redirect_uri` provided by the Client MUST be included in the registration `redirect_uris` +list. + +This example uses [JSON-LD ](https://www.w3.org/TR/json-ld/) for the Client ID Document: + +
+

https://app.example/id

+ + 
+        {
+          "@context": ["https://www.w3.org/ns/solid/oidc-context.jsonld"],
+
+          "client_id": "https://app.example/id",
+          "client_name": "Solid Application Name",
+          "redirect_uris": ["https://app.example/callback"],
+          "post_logout_redirect_uris": ["https://app.example/logout"],
+          "client_uri": "https://app.example/",
+          "logo_uri" : "https://app.example/logo.png",
+          "tos_uri" : "https://app.example/tos.html",
+          "scope" : "openid profile offline_access webid",
+          "grant_types" : ["refresh_token","authorization_code"],
+          "response_types" : ["code"],
+          "default_max_age" : 3600,
+          "require_auth_time" : true
+        }
+
+
+ +Issue(95): + +### JSON-LD context ### {#jsonld-context} + +This specification defines a JSON-LD context for use with OIDC Client ID Documents. This context is +available at `https://www.w3.org/ns/solid/oidc-context.jsonld`. Client ID Documents that reference +this JSON-LD context MUST use the HTTPS scheme. + +NOTE: the [Solid-OIDC Vocabulary](https://www.w3.org/ns/solid/oidc) that is part of this context uses the HTTP scheme. + +Full content of JSON-LD context can be also seen in [[#full-jsonld-context]] + +## OIDC Registration ## {#clientids-oidc} + +For non-dereferencable identifiers, the Client MUST present a `client_id` value that has been +registered with the OP via either OIDC dynamic or static registration. +See also [[!OIDC-DYNAMIC-CLIENT-REGISTRATION]]. + +When requesting Dynamic Client Registration, the Client MUST specify the `scope` in the metadata +and include `webid` in its value (space-separated list). + +
+ 
+        {
+          "client_name": "S-C-A Browser Demo Client App",
+          "application_type": "web",
+          "redirect_uris": [
+            "https://dynamic-client.example/auth"
+          ],
+          "subject_type": "pairwise",
+          "token_endpoint_auth_method": "client_secret_basic",
+          "scope" : "openid profile offline_access webid"
+        }
+
+
+ +# WebID Profile # {#webid-profile} + +Dereferencing the WebID URL results in a WebID Profile. + +Issue(76): + +## OIDC Issuer Discovery ## {#oidc-issuer-discovery} + +A WebID Profile lists the OpenID Providers who are trusted to issue tokens on behalf +of the agent who controls the WebID. This prevents a malicious OpenID Provider from issuing +otherwise valid ID Tokens for arbitrary WebIDs. An entity that verifies ID Tokens will use this +mechanism to determine if the issuer is authoritative for the given WebID. + +
+ 
+      PREFIX solid: <http://www.w3.org/ns/solid/terms#>
+
+      <#id> solid:oidcIssuer <https://oidc.example> .
+
+
WebID Profile specifying an OIDC issuer
+
+ +To discover a list of valid issuers, the WebID Profile MUST be checked for the existence of statements matching +
+  ?webid <http://www.w3.org/ns/solid/terms#oidcIssuer> ?iss .
+
+where `?webid` is set to WebID. The `?iss` will result in an IRI denoting valid issuer for that WebID. +The WebID Profile Document MUST include one or more statements matching the OIDC issuer pattern. + +Issue(80): + +Issue(92): + +Issue(91): + +### OIDC Issuer Discovery via Link Headers ### {#oidc-issuer-discovery-link-headers} + +A server hosting a WebID Profile Document MAY transmit the `http://www.w3.org/ns/solid/terms#oidcIssuer` +values via Link Headers, but they MUST be the same as in the RDF representation. +A client MUST treat the RDF in the body of the WebID Profile as canonical +but MAY use the Link Header values as an optimization. + +
+ 
+        Link: <https://oidc.example>;
+              rel="http://www.w3.org/ns/solid/terms#oidcIssuer";
+              anchor="#id"
+
+
HTTP response Link Header (line breaks added for readibility)
+
+ + +# Requesting the WebID Claim using a Scope Value # {#webid-scope} + +Solid-OIDC uses scope values, as defined in [[!RFC6749]] Section 3.3 and [[!OIDC-CORE]] Section 5.4 to specify +what information is made available as Claim Values. + +Solid-OIDC defines the following `scope` value for use with claim requests: + +
+
*webid* +
+ REQUIRED. This scope requests access to the End-User's `webid` Claim. +
+ + +# 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. +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. +The value of the `iss` parameter MUST be the Issuer Identifier of the OP, as defined in [[OIDC-CORE]]. +
+ 
+HTTP/1.1 302 Found
+Location: https://client.example.com/callback?
+                                        code=n0esc392ae491076
+                                        &state=af0ifjsldkj
+                                        &iss=https%3A%2F%2Fidp.example.com
+
+
Example Authorization Response including the `iss` query parameter
+
+ +Upon receiving the authorization response, the Client MUST validate the `iss` parameter: +* The Client MUST check for the presence of the `iss` parameter. +* The Client MUST verify that the `iss` value matches the Issuer Identifier of the OP to which the authorization request was sent. + +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. + + +# Token Instantiation # {#tokens} + +Assuming one of the following options + - 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. + +## DPoP-bound OIDC ID Token ## {#tokens-id} + +When requesting a DPoP-bound OIDC ID Token, the Client MUST send a DPoP proof JWT +that is valid according to the [[DPOP#section-5]]. The DPoP proof JWT is used to +bind the OIDC ID Token to a public key. See also: [[!DPOP]]. + +With the `webid` scope, the DPoP-bound OIDC ID Token payload MUST contain these claims: + * `webid` — The WebID claim MUST be the user's WebID. + * `iss` — The issuer claim MUST be a valid URL of the OP + instantiating this token. + * `aud` — The audience claim MUST be an array of values. + The values MUST include the authorized party claim `azp` + and the string `solid`. + In the decentralized world + of Solid-OIDC, the audience of an ID Token is not only the client (`azp`), + but also any Solid Authorization Server at any accessible address + on the world wide web (`solid`). See also: [[RFC7519#section-4.1.3]]. + * `azp` - The authorized party claim is used to identify the client + (See also: [section 5. Client Identifiers](#clientids)). + * `iat` — The issued-at claim is the time at which the DPoP-bound + OIDC ID Token was issued. + * `exp` — The expiration claim is the time at which the DPoP-bound + OIDC ID Token becomes invalid. + * `cnf` — The confirmation claim is used to identify the DPoP Public + Key bound to the OIDC ID Token. See also: [[DPOP#section-7]]. + +
+

An example OIDC ID Token: + + 

+        {
+            "webid": "https://janedoe.com/web#id",
+            "iss": "https://idp.example.com",
+            "sub": "janedoe",
+            "aud": ["https://client.example.com/client_id", "solid"],
+            "azp": "https://client.example.com/client_id",
+            "iat": 1311280970,
+            "exp": 1311281970,
+            "cnf":{
+              "jkt":"0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I"
+            }
+        }
+
+
+ +Issue(26): + +Issue(47): + +### ID Token Validation ### {#id-token-validation} + +An ID Token must be validated according to [OIDC-CORE, Section 3.1.3.7](https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation) + +The Verifying party MUST perform [[#oidc-issuer-discovery]] using the value of the `webid` claim +to dereference the WebID Profile Document. + +Unless the verifying party acquires OP keys through some other means, or it chooses to reject tokens issued by this OP, +the verifying party MUST follow OpenID Connect Discovery 1.0 [[!OIDC-DISCOVERY]] to find an OP's signing keys (JWK). + +# Resource Access # {#resource} + +## Authorization Server Discovery ## {#authorization-server-discovery} + +When a Client performs an unauthenticated request to a protected resource, +the Resource Server MUST respond with the HTTP 401 status code, +and a WWW-Authenticate HTTP header. See also: [[RFC9110]](11.6.1. WWW-Authenticate) + +The WWW-Authenticate HTTP header MUST include an as_uri +parameter unless the authentication scheme requires a different mechanism +for discovering an associated authorization server. + +Authorization Servers SHOULD implement User-Managed Access (UMA) 2.0 Grant for +OAuth 2.0 Authorization [[!UMA]]. + +## Obtaining an Access Token ## {#obtaining-access-token} + +For Authorization Servers that conform to [[!UMA]], the +http://openid.net/specs/openid-connect-core-1_0.html#IDToken profile MUST +be supported. This profile MUST be advertised in the uma_profiles_supported +metadata of the Authorization Server discovery document [[UMA#rfc.section.2]]. + +When using the http://openid.net/specs/openid-connect-core-1_0.html#IDToken +profile with an UMA-based Authorization Server, the Authorization Server MUST be capable +of exchanging a valid Solid-OIDC ID Token [[#tokens-id]] for an OAuth 2.0 Access Token. + +Note: Clients can push additional claims by requesting an upgraded RPT [[UMA#rfc.section.3.3.1]] + +Authorization Server MUST pefrom [[#dpop-validation]] and [[#id-token-validation]] + +## DPoP Validation ## {#dpop-validation} + +A DPoP Proof that is valid according to +[DPoP Internet-Draft, Section 4.3](https://tools.ietf.org/html/draft-ietf-oauth-dpop-04#section-4.3), +MUST be present when a DPoP-bound OIDC ID Token is used. + +The DPoP-bound OIDC ID Token MUST be validated according to +[DPoP Internet-Draft, Section 6](https://tools.ietf.org/html/draft-ietf-oauth-dpop-04#section-6), +but the AS MAY perform additional verification in order to determine whether to grant access to the +requested resource. + +# Solid-OIDC Conformance Discovery # {#discovery} + +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. + +
+ 
+        {
+            "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 SHOULD 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](https://www.rfc-editor.org/rfc/rfc6749#section-1.5), when supported by the server. + +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* + +
+ When using the Client Credentials Grant, a Client could authenticate with the OP using a `client_id` + 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. +
+ +NOTE: [[!RFC7523]] (Section 2.2) presents another way to handle authentication using JWTs. + +## 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's authentication +credentials. + +## Solid-OIDC Conformance Discovery ## {#client-credentials-discovery} + +For non-interactive use cases such as scripts, automated agents, and server-to-server communication, an OpenID Provider +that supports the [Client Credentials Grant](https://www.rfc-editor.org/rfc/rfc6749#section-4.4) MUST advertise that +support in the OpenID Connect Discovery 1.0 [OIDC.Discovery] resource by including `client_credentials` in its +`grant_types_supported` metadata property. + +
+ 
+        {
+            "grant_types_supported": ["authorization_code", "refresh_token", "client_credentials"]
+        }
+
+
+ +# Security Considerations # {#security} + +*This section is non-normative* + +As this specification builds upon existing web standards, security considerations from OAuth, OIDC, +PKCE, and the DPoP specifications may also apply unless otherwise indicated. The following +considerations should be reviewed by implementors and system/s architects of this specification. + +Some of the references within this specification point to documents with a +Living Standard or Draft status, meaning their contents can still change over +time. It is advised to monitor these documents, as such changes might have +security implications. + +In addition to above considerations, implementors should consider the Security +Considerations in context of the Solid Protocol [[!SOLID-PROTOCOL]]. + +## TLS Requirements ## {#security-tls} + +All TLS requirements outlined in [[BCP195]] apply to this +specification. + +All tokens, Client, and User credentials MUST only be transmitted over TLS. + +## Client IDs ## {#security-client-ids} + +An AS SHOULD assign a fixed set of low trust policies to any client identified as anonymous. + +Implementors SHOULD expire ephemeral Client IDs that are kept in server storage to mitigate the +potential for a bad actor to fill server storage with unexpired or otherwise useless Client IDs. + +## Client Secrets ## {#security-client-secrets} + +Client secrets SHOULD NOT be stored in browser local storage. Doing so will increase the risk of +data leaks should an attacker gain access to Client credentials. + +## Client Trust ## {#security-client-trust} + +*This section is non-normative* + +Clients are ephemeral, client registration is optional, and most Clients cannot keep secrets. These, +among other factors, are what makes Client trust challenging. + +## Issuer Trust ## {#security-issuer-trust} + +*This section is non-normative* + +A Solid-OIDC user's identity is asserted by the OpenID Provider listed in their WebID Profile via +`solid:oidcIssuer`. Implementers and end-users should consider the trust they place in that issuer: + +* **User trusts identity provider to be honest.** The user's chosen identity provider is able to assert the identity of the user in an issued identity token. The user relies on the identity provider to obtain such identity token and trusts the identity provider not to issue such token of the user's identity to a different user or to use that token themselves. A compromised or malicious identity provider is able to let other malicious agents impersonate the user or to impersonate the user themself. If the user's identity provider is unavailable, the user is unable to obtain an identity token, which might lead the user to be unable to access data that requires authentication and thereby implicitly denying access to data. A high degree of trust in the chosen identity provider is therefore necessary. +The authorization server has to choose to trust the identity provider selected by the user before granting access. This choice may be to delegate the choice completely to users, or to restrict the set of identity providers to a specific trust list. + +* **Identity Provider as a Single Point of Failure.** When an agent has only one identity provider, only that single identity provider is able to assert the identity of the agent. In case this identity provider is unavailable, the agent is unable to authenticate itself. +Agents may have multiple identity providers. Having multiple identity providers can provide redundancy in the event of an outage of one identity provider service. The trade-off is that this increases the attack surface of malicious identity providers. +Where many agents share a single identity provider, that identity provider is a concentration point: a single compromise, outage, or service-level decision affects every agent that depends on it. Attacks tend to focus on major centralization, so concentration risk grows with the issuer's user base. Implementations offering accounts under a shared issuer should plan for this risk. + +# Privacy Considerations # {#privacy} + +## OIDC ID Token Reuse ## {#privacy-token-reuse} + +*This section is non-normative* + +With JWTs being extendable by design, there is potential for a privacy breach if OIDC ID Tokens get +reused across multiple authorization servers. It is not unimaginable that a custom claim is added to the +OIDC ID Token on instantiation. This addition may unintentionally give other authorization servers +consuming the OIDC ID Token information about the user that they may not wish to share outside of the +intended AS. + +# Acknowledgments # {#acknowledgments} + +*This section is non-normative* + +The Solid Community Group would like to thank the following individuals for reviewing and providing +feedback on the specification (in alphabetical order): + +Tim Berners-Lee, Justin Bingham, Sarven Capadisli, Aaron Coburn, Matthias Evering, Jamie Fiedler, +Michiel de Jong, Ted Thibodeau Jr, Kjetil Kjernsmo, Mitzi László, Pat McBennett, Adam Migus, Jackson Morgan, Davi +Ottenheimer, Justin Richer, severin-dsr, Henry Story, Michael Thornburgh, Emmet Townsend, Ruben +Verborgh, Ricky White, Paul Worrall, Dmitri Zagidulin. + +# Appendix A: Full JSON-LD context # {#full-jsonld-context} + +The JSON-LD context is defined as: + +
+  {
+    "@context": {
+      "@version": 1.1,
+      "@protected": true,
+      "oidc": "http://www.w3.org/ns/solid/oidc#",
+      "xsd": "http://www.w3.org/2001/XMLSchema#",
+      "client_id": {
+        "@id": "@id",
+        "@type": "@id"
+      },
+      "client_uri": {
+        "@id": "oidc:client_uri",
+        "@type": "@id"
+      },
+      "logo_uri": {
+        "@id": "oidc:logo_uri",
+        "@type": "@id"
+      },
+      "policy_uri": {
+        "@id": "oidc:policy_uri",
+        "@type": "@id"
+      },
+      "tos_uri": {
+        "@id": "oidc:tos_uri",
+        "@type": "@id"
+      },
+      "redirect_uris": {
+        "@id": "oidc:redirect_uris",
+        "@type": "@id",
+        "@container": [
+          "@id",
+          "@set"
+        ]
+      },
+      "require_auth_time": {
+        "@id": "oidc:require_auth_time",
+        "@type": "xsd:boolean"
+      },
+      "default_max_age": {
+        "@id": "oidc:default_max_age",
+        "@type": "xsd:integer"
+      },
+      "application_type": {
+        "@id": "oidc:application_type"
+      },
+      "client_name": {
+        "@id": "oidc:client_name"
+      },
+      "contacts": {
+        "@id": "oidc:contacts"
+      },
+      "grant_types": {
+        "@id": "oidc:grant_types"
+      },
+      "response_types": {
+        "@id": "oidc:response_types"
+      },
+      "scope": {
+        "@id": "oidc:scope"
+      },
+      "token_endpoint_auth_method": {
+        "@id": "oidc:token_endpoint_auth_method"
+      }
+    }
+  }
+
+ +
+{
+    "DPOP": {
+        "authors": [
+            "D. Fett",
+            "B. Campbell",
+            "J. Bradley",
+            "T. Lodderstedt",
+            "M. Jones",
+            "D. Waite"
+        ],
+        "href": "https://tools.ietf.org/html/draft-ietf-oauth-dpop",
+        "title": "OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer (DPoP)",
+        "publisher": "IETF"
+    },
+    "OIDC-CORE": {
+        "authors": [
+            "N. Sakimura",
+            "J. Bradley",
+            "M. Jones",
+            "B. de Medeiros",
+            "C. Mortimore"
+        ],
+        "href": "https://openid.net/specs/openid-connect-core-1_0.html",
+        "title": "OpenID Connect Core 1.0",
+        "publisher": "The OpenID Foundation"
+    },
+    "OIDC-DISCOVERY": {
+        "authors": [
+            "N. Sakimura",
+            "J. Bradley",
+            "M. Jones",
+            "E. Jay"
+        ],
+        "href": "https://openid.net/specs/openid-connect-discovery-1_0.html",
+        "title": "OpenID Connect Discovery 1.0",
+        "publisher": "The OpenID Foundation"
+    },
+    "OIDC-DYNAMIC-CLIENT-REGISTRATION": {
+        "authors": [
+            "N. Sakimura",
+            "J. Bradley",
+            "M.B. Jones"
+        ],
+        "href": "https://openid.net/specs/openid-connect-registration-1_0.html",
+        "title": "OpenID Connect Dynamic Client Registration 1.0",
+        "publisher": "The OpenID Foundation"
+    },
+    "SOLID-PROTOCOL": {
+        "authors": [
+            "Sarven Capadisli",
+            "Tim Berners-Lee",
+            "Ruben Verborgh",
+            "Kjetil Kjernsmo",
+            "Justin Bingham",
+            "Dmitri Zagidulin"
+        ],
+        "href": "https://solidproject.org/TR/protocol",
+        "title": "Solid Protocol",
+        "publisher": "W3C Solid Community Group"
+    },
+    "SOLID-OIDC-PRIMER": {
+        "authors": [
+            "Jackson Morgan",
+            "Aaron Coburn",
+            "Matthieu Bosquet"
+        ],
+        "href": "https://solid.github.io/solid-oidc/primer/",
+        "title": "Solid-OIDC Primer",
+        "publisher": "W3C Solid Community Group"
+    },
+    "WEBID": {
+        "authors": [
+            "Andrei Sambra",
+            "Henry Story",
+            "Tim Berners-Lee"
+        ],
+        "href": "https://www.w3.org/2005/Incubator/webid/spec/identity/",
+        "title": "WebID 1.0",
+        "publisher": "WebID Incubator Group"
+    },
+    "UMA": {
+        "authors": [
+            "Eve Maler",
+            "Maciej Machulak",
+            "Justin Richer"
+        ],
+        "href": "https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html",
+        "title": "User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization",
+        "publisher": "Kantara Initiative, Inc"
+    },
+    "BCP195": {
+        "href": "https://www.rfc-editor.org/info/bcp195",
+        "title": "Best Current Practice 195",
+        "publisher": "IETF"
+    }
+}
+
diff --git a/primer/index.bs b/primer/index.bs index 7bd2bdd..5e863e8 100644 --- a/primer/index.bs +++ b/primer/index.bs @@ -4,8 +4,9 @@ Boilerplate: issues-index no Boilerplate: omit conformance Shortname: solid-oidc-primer Level: 1 -Status: CG-DRAFT +Org: W3C Group: solidcg +Status: CG-DRAFT ED: https://solid.github.io/solid-oidc/primer/ TR: https://solidproject.org/TR/oidc-primer !Created: March 28, 2022 @@ -13,11 +14,11 @@ TR: https://solidproject.org/TR/oidc-primer Repository: https://github.com/solid/solid-oidc Markup Shorthands: markdown yes Max ToC Depth: 2 -Editor: [Jackson Morgan](https://github.com/jaxoncreed) -Editor: [Aaron Coburn](https://github.com/acoburn) -Editor: [Matthieu Bosquet](https://github.com/matthieubosquet) -Editor: [elf Pavlik](https://elf-pavlik.hackers4peace.net) -Editor: Christoph Braun (Forschungszentrum Informatik (FZI)) +Editor: Jackson Morgan, https://github.com/jaxoncreed +Editor: Aaron Coburn, Inrupt https://inrupt.com, https://github.com/acoburn +Editor: Matthieu Bosquet, https://github.com/matthieubosquet +Editor: elf Pavlik, https://elf-pavlik.hackers4peace.net +Editor: Christoph Braun, Forschungszentrum Informatik (FZI) https://www.fzi.de, https://github.com/uvdsl Metadata Order: This version, Latest published version, Test Suite, Created, Modified, *, !* Abstract: The Solid OpenID Connect (Solid-OIDC) specification defines how resource servers @@ -557,7 +558,7 @@ Token Body: { "sub": "https://alice.coolpod.example/profile/card#me", "aud": [ "solid", "https://decentphotos.example/client_id"], - "azp": "https://decentphotos.example/client_id" + "azp": "https://decentphotos.example/client_id", "webid": "https://alice.coolpod.example/profile/card#me", "iss": "https://secureauth.example", "jti": "844a095c-9cdb-47e5-9510-1dba987c0a5f", diff --git a/setup.sh b/setup.sh index d3d7dcc..fa63116 100755 --- a/setup.sh +++ b/setup.sh @@ -5,5 +5,11 @@ # pipx install bikeshed # bikeshed update (to get the latest autolinking data) -for bsdoc in ./*.bs ./**/*.bs; do bikeshed spec $bsdoc; done -for diagram in primer/*.mmd; do docker run --rm -v "$PWD:/data" minlag/mermaid-cli -i /data/$diagram; done +# Enable recursive globbing for ** +shopt -s globstar + +# 1. Generate ALL diagrams +for diagram in ./*.mmd ./**/*.mmd; do [ -f "$diagram" ] && docker run --rm -u $(id -u):$(id -g) -v "$PWD:/data" minlag/mermaid-cli -i "/data/$diagram"; done + +# 2. Build ALL specs +for bsdoc in ./*.bs ./**/*.bs; do [ -f "$bsdoc" ] && bikeshed spec "$bsdoc"; done \ No newline at end of file From 489ec7c50e3d17cddffb830ff33c9542e8e77761 Mon Sep 17 00:00:00 2001 From: Christoph Braun Date: Thu, 18 Jun 2026 18:19:35 +0200 Subject: [PATCH 5/5] add indentation to make automatic build happy --- index.bs | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/index.bs b/index.bs index 8ee103f..3b08aee 100644 --- a/index.bs +++ b/index.bs @@ -534,11 +534,11 @@ A Solid-OIDC user's identity is asserted by the OpenID Provider listed in their `solid:oidcIssuer`. Implementers and end-users should consider the trust they place in that issuer: * **User trusts identity provider to be honest.** The user's chosen identity provider is able to assert the identity of the user in an issued identity token. The user relies on the identity provider to obtain such identity token and trusts the identity provider not to issue such token of the user's identity to a different user or to use that token themselves. A compromised or malicious identity provider is able to let other malicious agents impersonate the user or to impersonate the user themself. If the user's identity provider is unavailable, the user is unable to obtain an identity token, which might lead the user to be unable to access data that requires authentication and thereby implicitly denying access to data. A high degree of trust in the chosen identity provider is therefore necessary. -The authorization server has to choose to trust the identity provider selected by the user before granting access. This choice may be to delegate the choice completely to users, or to restrict the set of identity providers to a specific trust list. + The authorization server has to choose to trust the identity provider selected by the user before granting access. This choice may be to delegate the choice completely to users, or to restrict the set of identity providers to a specific trust list. * **Identity Provider as a Single Point of Failure.** When an agent has only one identity provider, only that single identity provider is able to assert the identity of the agent. In case this identity provider is unavailable, the agent is unable to authenticate itself. -Agents may have multiple identity providers. Having multiple identity providers can provide redundancy in the event of an outage of one identity provider service. The trade-off is that this increases the attack surface of malicious identity providers. -Where many agents share a single identity provider, that identity provider is a concentration point: a single compromise, outage, or service-level decision affects every agent that depends on it. Attacks tend to focus on major centralization, so concentration risk grows with the issuer's user base. Implementations offering accounts under a shared issuer should plan for this risk. + Agents may have multiple identity providers. Having multiple identity providers can provide redundancy in the event of an outage of one identity provider service. The trade-off is that this increases the attack surface of malicious identity providers. + Where many agents share a single identity provider, that identity provider is a concentration point: a single compromise, outage, or service-level decision affects every agent that depends on it. Attacks tend to focus on major centralization, so concentration risk grows with the issuer's user base. Implementations offering accounts under a shared issuer should plan for this risk. # Privacy Considerations # {#privacy}