This document defines an OpenID Connect-based authentication suite for the Linked Web Storage (LWS) protocol, enabling LWS applications to integrate with OpenID providers.
This is an unofficial proposal.
OpenID Connect is a widely used mechanism for web-based authentication. This authentication suite describes how an OpenID provider can be used with Linked Web Storage-conforming applications.
The terms "authorization server" and "client" are defined by The OAuth 2.0 Authorization Framework [[!RFC6749]].
The terms "OpenID provider", "id token", "end-user", and "issuer" are defined by OpenID Connect Core 1.0 [[!OPENID-CONNECT-CORE]].
The term "openid connect discovery" is defined by OpenID Connect Discovery 1.0 [[!OPENID-CONNECT-DISCOVERY]].
The term "controlled identifier document" is defined by W3C Controlled Identifiers 1.0 [[!CID-1.0]].
The terms "JSON Web Token (JWT)" and "claim" are defined by JSON Web Token [[!RFC7519]].
The term "JSON Web Key (JWK)" is defined by JSON Web Key [[!RFC7517]].
The terms "agent", "authentication credential", and "authentication suite" are defined by Linked Web Storage Protocol [[!LWS10-CORE]]
OpenID Connect defines a protocol for producing signed ID Tokens, which are used to describe an end-user. An ID Token is serialized as a signed JSON Web Token (JWT). In order to use an ID Token as an LWS authentication credential, the following additional requirements apply.
sub (subject) claim for the LWS subject identifier.
iss (issuer) claim for the LWS issuer identifier.
azp (authorized party) claim for the LWS client identifier.
aud (audience) claim.
The aud claim SHOULD include the client identifier and any additional target
audience such as an authorization server.
An example ID Token that is also an LWS authentication credential is included below.
{
"typ": "JWT",
"kid": "12dbe73a",
"kty": "EC",
"alg": "ES256",
"crv": "P-256"
}
.
{
"sub": "https://id.example/end-user",
"iss": "https://openid.example",
"azp": "https://client.example/17da1b",
"aud": ["https://client.example/17da1b", "https://as.example"],
"iat": 1761313600,
"exp": 1761313900
}
.
signature
For an ID Token to validate as an LWS authentication credential, there must be a trust relationship between the verifier and the issuing party.
In the absence of a pre-existing trust relationship, the validator MUST dereference the sub (subject) claim in the authentication credential.
The resulting resource MUST be formatted as a valid controlled identifier document [[!CID-1.0]] with an id value equal to the subject identifier.
The verifier MUST use the subject's controlled identifier document to locate a service object whose serviceEndpoint value
is equal to the value of the iss claim from the authentication credential, and whose type value is equal to https://www.w3.org/ns/lws#OpenIdProvider.
The verifier MUST perform OpenID Connect Discovery to locate the public portion of the JSON Web Key (JWK) used to sign the authentication credential.
The JWT MUST be validated as described by OpenID Connect Core Section 3.1.3.7 [[!OPENID-CONNECT-CORE]].
An example Controlled Identifier Document for an agent using OpenID Connect is included below.
{
"@context": [
"https://www.w3.org/ns/cid/v1"
],
"id": "https://id.example/end-user",
"service": [{
"type": "https://www.w3.org/ns/lws#OpenIdProvider",
"serviceEndpoint": "https://openid.example"
}]
}
An ID Token used as an authentication credential MUST use the urn:ietf:params:oauth:token-type:id_token URI when interacting with an authorization server.
All security considerations described in "Best Current Practice for OAuth 2.0 Security" [[RFC9700]] and "OpenID Connect Core 1.0" Section 16 [[OPENID-CONNECT-CORE]] apply to this specification.
An OpenID provider should support a mechanism to restrict the audience of an authentication credential to a limited set of entities, including an authorization server. One mechanism for achieving this is to use Resource Indicators for OAuth 2.0 [[RFC8707]]. A client in possession of an authentication credential with no audience restrictions should exchange this token for an equivalent audience-restricted token by using, for example, OAuth 2.0 Token Exchange [[RFC8693]].
An OpenID provider should provide support for "OAuth 2.0 Authorization Server Issuer Identification" [[RFC9207]] by including an iss parameter in the authorization response of an OAuth flow.
An OpenID provider should provide support for end-user logout, such as RP-Initiated Logout 1.0.
The issuer of an authentication credential is responsible for validating the client identifier. The issuer may use mechanisms such as an OAuth Client ID Metadata Document, an OAuth 2.0 Client ID Prefix, or OpenID Federation.
It is recommended that OpenID providers support WebAuthn [[WEBAUTHN-3]] as a mechanism for authenticating users.
All privacy considerations described in "OpenID Connect Core 1.0" Section 17 [[OPENID-CONNECT-CORE]] apply to this specification.
An ID Token used as an authentication credential can contain claims that reveal
personally identifiable information about the end-user, such as email addresses,
names, or other profile attributes. OpenID providers are encouraged to issue ID Tokens
that contain only the claims necessary for LWS authentication — specifically, the
sub, iss, azp, and aud claims —
and to avoid including additional identity attributes unless explicitly required.
Because the sub (subject) claim is used as the LWS subject identifier and
can be dereferenced during validation, the choice of subject identifier has privacy
implications. A persistent, globally unique subject identifier allows verifiers and
storage servers to correlate an end-user's activity across sessions and resources.
OpenID providers that support pairwise subject identifiers (as described in
[[OPENID-CONNECT-CORE]] Section 8) can reduce the potential for cross-provider
correlation, though the LWS validation model requires the subject identifier
to resolve to a controlled identifier document.
The validation process requires dereferencing the subject identifier to retrieve a controlled identifier document. This dereference operation can reveal to the hosting server of that document which verifiers are validating credentials for a given subject, including timing and frequency of access. Verifiers are encouraged to cache controlled identifier documents to reduce unnecessary network requests and the associated metadata leakage.
Clients and relying parties are advised that an ID Token presented to a storage
server or authorization server can be read by those parties. Audience restriction
(via the aud claim) limits which parties the token is intended for but
does not prevent an intermediary from reading the token's contents in transit.
The use of TLS is essential for protecting authentication credentials during transmission.