LWS 1.0 Authentication Suite: OpenID Connect

W3C First Public Working Draft

More details about this document
This version:
https://www.w3.org/TR/2026/WD-lws10-authn-openid-20260423/
Latest published version:
https://www.w3.org/TR/lws10-authn-openid/
Latest editor's draft:
https://w3c.github.io/lws-protocol/
History:
https://www.w3.org/standards/history/lws10-authn-openid/
Commit history
Editor:
Jesse Wright (University of Oxford)
Author:
Aaron Coburn (Inrupt Inc.)
Feedback:
GitHub w3c/lws-protocol (pull requests, new issue, open issues)

Abstract

This document defines an OpenID Connect-based authentication suite for the Linked Web Storage (LWS) protocol, enabling LWS applications to integrate with OpenID providers.

Status of This Document

This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C standards and drafts index.

This is an unofficial proposal.

This document was published by the Linked Web Storage Working Group as a First Public Working Draft using the Recommendation track.

Publication as a First Public Working Draft does not imply endorsement by W3C and its Members.

This is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to cite this document as other than a work in progress.

This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent that the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 18 August 2025 W3C Process Document.

1. Introduction

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.

2. Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MUST, MUST NOT, and SHOULD in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Terminology

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 "authentication credential" and "authentication suite" are defined by Linked Web Storage Protocol [LWS-PROTOCOL]

4. Authentication Credential Serialization

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.

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

5. Authentication Credential Validation

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"
    }]
}

6. Token Type Identifier

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.

7. Security Considerations

This section is non-normative.

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.

8. Privacy Considerations

This section is non-normative.

Issue 119: Add Privacy Considerations sections to the authentication suites

This section needs to be completed.

A. References

A.1 Normative references

[CID-1.0]
Controlled Identifiers v1.0. Michael Jones; Manu Sporny. W3C. 15 May 2025. W3C Recommendation. URL: https://www.w3.org/TR/cid-1.0/
[LWS-PROTOCOL]
LWS Protocol. W3C. FPWD. URL: https://www.w3.org/TR/lws-core/
[OPENID-CONNECT-CORE]
OpenID Connect Core 1.0 incorporating errata set 2. N. Sakimura; J. Bradley; M. Jones; B. de Medeiros; C. Mortimore. OpenID Foundation. 15 December 2023. Final. URL: https://openid.net/specs/openid-connect-core-1_0.html
[OPENID-CONNECT-DISCOVERY]
OpenID Connect Discovery 1.0 incorporating errata set 2. N. Sakimura; J. Bradley; M. Jones; E. Jay. OpenID Foundation. 15 December 2023. Final. URL: https://openid.net/specs/openid-connect-discovery-1_0.html
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC6749]
The OAuth 2.0 Authorization Framework. D. Hardt, Ed. IETF. October 2012. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc6749
[RFC7517]
JSON Web Key (JWK). M. Jones. IETF. May 2015. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc7517
[RFC7519]
JSON Web Token (JWT). M. Jones; J. Bradley; N. Sakimura. IETF. May 2015. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc7519
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174

A.2 Informative references

[RFC8693]
OAuth 2.0 Token Exchange. M. Jones; A. Nadalin; B. Campbell, Ed.; J. Bradley; C. Mortimore. IETF. January 2020. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc8693
[RFC8707]
Resource Indicators for OAuth 2.0. B. Campbell; J. Bradley; H. Tschofenig. IETF. February 2020. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc8707
[RFC9207]
OAuth 2.0 Authorization Server Issuer Identification. K. Meyer zu Selhausen; D. Fett. IETF. March 2022. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc9207
[RFC9700]
Best Current Practice for OAuth 2.0 Security. T. Lodderstedt; J. Bradley; A. Labunets; D. Fett. IETF. January 2025. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc9700
[WEBAUTHN-3]
Web Authentication: An API for accessing Public Key Credentials - Level 3. Michael Jones; Akshay Kumar; Emil Lundberg; Tim Cappalli; Matthew Miller. W3C. 13 January 2026. W3C Candidate Recommendation. URL: https://www.w3.org/TR/webauthn-3/