1. Introduction
This section is non-normative
The Solid project 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 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:
-
Resource servers and their Authorization servers having no existing trust relationship with identity providers.
-
Ephemeral Clients as a first-order use-case.
1.1. Out of Scope
This section is non-normative
At the time of writing, there is no demonstrated use case for a strongly asserted identity; however, it is likely that authorization requirements will necessitate it.
2. Terminology
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.
3. Core 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 any case, the user may be authenticating from a browser or an application.
Therefore, this specification assumes the use of the Authorization Code Flow 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.
3.1. 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. 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.
4. Basic Flow
This section is non-normative
Details of the flow are available in [Solid.OIDC.Primer]
5. Client Identifiers
OAuth and OIDC require the Client application to identify itself to the OP and RS by presenting a client identifier (Client ID). Solid applications SHOULD use a URI that can be dereferenced as a Client ID Document.
5.1. Client ID 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 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 }
5.1.1. JSON-LD 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 oidc
vocabulary that is part of this context uses the HTTP scheme.
Full content of JSON-LD context can be also seen in Appendix A: Full JSON-LD context
5.2. OIDC Registration
If the Client does not use an identifier that can be dereferenced, then it MUST present a client identifier registered with the OP via either OIDC dynamic or static registration. See also [OIDC.DynamicClientRegistration].
6. WebID Profile
Dereferencing the WebID URL results in a WebID Profile.
6.1. 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.
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.
6.1.1. OIDC Issuer Discovery via 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.
7. Requesting the WebID Claim using a Scope Value
In OpenID Connect, scope
values are used to request that particular information be make 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.
8. Token Instantiation
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.
8.1. DPoP-bound OIDC ID Token
When requesting a DPoP-bound OIDC ID Token, the Client MUST send a DPoP proof JWT that is valid according to the OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer (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 claimazp
and the stringsolid
. 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: JSON Web Token (JWT) § section-4.1.3. -
azp
- The authorized party claim is used to identify the client (See also: section 5. Client Identifiers). -
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: OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer (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/web#id" , "solid" ], "azp" : "https://client.example.com/web#id" , "iat" :<PHONE_NUMBER> , "exp" :<PHONE_NUMBER> , "cnf" :{ "jkt" : "0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I" } }
8.1.1. ID Token Validation
An ID Token must be validated according to OIDC.Core, Section <IP_ADDRESS>
The Verifying party MUST perform § 6.1 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).
9. Resource Access
9.1. 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: Hypertext Transfer Protocol (HTTP/1.1): Authentication § section-4.1
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].
9.2. Obtaining an 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 User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization § 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 § 8.1 DPoP-bound OIDC ID Token for an OAuth 2.0 Access Token.
Note: Clients can push additional claims by requesting an upgraded RPT User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization § rfc.section.3.3.1
Authorization Server MUST pefrom § 9.3 DPoP Validation and § 8.1.1 ID Token Validation
9.3. DPoP Validation
A DPoP Proof that is valid according to DPoP Internet-Draft, 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, but the AS MAY perform additional verification in order to determine whether to grant access to the requested resource.
10. Solid-OIDC Conformance 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.
11. Security Considerations
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].
11.1. TLS Requirements
All TLS requirements outlined in [BCP195] apply to this specification.
All tokens, Client, and User credentials MUST only be transmitted over TLS.
11.2. 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.
11.3. 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.
11.4. 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.
12. Privacy Considerations
12.1. OIDC ID 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.
13. 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
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" } } }


{% extends "layout-v2.html" %} {% block pageScripts %} {% endblock %} {% block pageTitle %} NHS Cervical screening management system {% endblock %} {% block header %} {% include '../../components/header.html' %} {% endblock %} {% block content %}
View and download all lab files
Enter the file details you wish to search by:
If you cannot find the file you're looking for refine the search.
| Lab and national code | File name | Date and time received | Number of results received | View summary and download CSVs |
|---|---|---|---|---|
| London 12345 | File 1 | 15-09-2021 11:30:10 | 8000 | View summary |
| Manchester 12345 | File 1 | 15-09-2021 11:30:10 | 1200 | View summary |
| Bristol 12345 | File 1 | 15-09-2021 11:30:10 | 890 | View summary |
| Bristol 12345 | File 2 | 15-09-2021 11:30:10 | 70 | View summary |
| Bristol 12345 | File 3 | 15-09-2021 11:30:10 | 543 | View summary |
| Bristol 12345 | File 4 | 15-09-2021 11:30:10 | 890 | View summary |
| Berkshire 12345 | File 1 | 15-09-2021 11:30:10 | 300 | View summary |
| Derby 12345 | File 1 | 15-09-2021 11:30:10 | 1000 | View summary |
| Gateshead 12345 | File 1 | 15-09-2021 11:30:10 | 600 | View summary |
| Norwich 12345 | File 1 | 15-09-2021 11:30:10 | 190 | View summary |
| Wolverhampton 12345 | File 1 | 15-09-2021 11:30:10 | 679 | View summary |


I work hard to separate the ideas and technologies I talk about here. This is a place where I try to connect all of my thoughts, things I often forget, the collection of latest technologies and small stuff I usually use to make my work and personal life more comfortable. This is an on-going responsibility to me.