Web Identity (WebID) 1.1 — UNOFFICIAL DRAFT

1. Introduction

This section is non-normative.

This draft explores how [WEBID-1.0] might be extended to address two areas:

1. HTTP Binding for Agent Identification: While [CID] defines the data model for controlled identifiers, it does not specify a transport protocol. This draft explores how WebID could provide the HTTP binding—defining how agent identifiers are dereferenced via HTTP to obtain identity documents.

2. LWS Compatibility: The [LWS-PROTOCOL] requires agent identifiers to be URIs that dereference to [CID] documents. This draft explores how WebID Documents could be served as valid CID documents through content negotiation.

1.1. Relationship to Other Specifications

1.2. Design Goals

Backward Compatibility

Existing WebID profiles in Turtle format remain valid WebID 1.1 documents.

CID Alignment

WebID Documents can simultaneously be valid CID documents via content negotiation.

LWS Integration

Enables WebID-based authentication suites for LWS without protocol changes.

Minimal Extension

Adds only what is necessary; does not duplicate CID or LWS functionality.

Continuity

This draft intentionally stays close to existing WebID deployments and avoids introducing new identifier schemes.

1.3. Non-Goals

This draft does not attempt to:

• Define or modify the [CID] specification itself

• Replace or compete with DID methods or other identifier schemes

• Propose a formal Working Group deliverable

• Mandate changes to existing Solid or LWS implementations

The goal is to explore possibilities, not to prescribe outcomes.

2. Terminology

This specification inherits all terms from [WEBID-1.0] and adds:

Controlled Identifier Document

A document conforming to [CID] that contains cryptographic material and service endpoints for verifying proofs from the document’s controller.

WebID-CID Document

A WebID Document that also conforms to [CID] requirements, enabling use in LWS authentication contexts.

HTTP Binding

The mechanism by which an identifier is dereferenced via HTTP to obtain its associated document. WebID defines the HTTP binding for agent identification.

2.1. Namespaces

3. WebID as HTTP Binding

[CID] defines a data model for controlled identifiers but explicitly states:

"The CID specification does not define the transport protocol or how a CID document is to be obtained."

WebID fills this gap by defining the HTTP binding for agent identification:

1. A WebID is an HTTP(S) URI identifying an Agent

2. Dereferencing a WebID via HTTP returns a WebID Document

3. The WebID Document describes the Agent and MAY include cryptographic material

This parallels how [LWS-PROTOCOL] provides a REST binding for CRUD operations.

4. WebID Document Formats

4.1. Content Negotiation

This draft explores a model where a Server hosting a WebID Document:

1. Treats application/ld+json (JSON-LD) as the primary representation for CID/LWS compatibility

2. Optionally supports text/turtle (Turtle) for backward compatibility with the Solid ecosystem

3. Uses HTTP content negotiation as the preferred method when supporting multiple formats

When a server supports both formats, clients can request their preferred representation using the HTTP Accept header. This would enable a single WebID to serve both LWS-native clients (JSON-LD) and legacy Solid clients (Turtle).

GET /profile HTTP/1.1
Host: alice.example
Accept: text/turtle

GET /profile HTTP/1.1
Host: alice.example
Accept: application/ld+json

4.2. Turtle Format (WebID 1.0 Compatible)

The Turtle representation MUST conform to [WEBID-1.0] requirements.

@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix solid: <http://www.w3.org/ns/solid/terms#> .

<> a foaf:PersonalProfileDocument ;
  foaf:maker <#me> ;
  foaf:primaryTopic <#me> .

<#me> a foaf:Person ;
  foaf:name "Alice" ;
  solid:oidcIssuer <https://idp.example/> .

4.3. JSON-LD Format (CID Compatible)

The JSON-LD representation MUST conform to [CID] requirements when used in LWS authentication contexts.

A WebID-CID Document MUST:

• Include the CID context

• Have an id property matching the WebID

• Include a service array with identity provider information

{
  "@context": [
    "https://www.w3.org/ns/cid/v1",
    {
      "foaf": "http://xmlns.com/foaf/0.1/",
      "name": "foaf:name",
      "Person": "foaf:Person"
    }
  ],
  "id": "https://alice.example/profile#me",
  "type": ["Person"],
  "name": "Alice",
  "service": [{
    "id": "https://alice.example/profile#oidc",
    "type": "OpenIdProvider",
    "serviceEndpoint": "https://idp.example/"
  }]
}

4.4. Equivalence

The Turtle and JSON-LD representations MUST be semantically equivalent—they represent the same RDF graph.

When a server supports both formats, the following mapping applies:

5. Verification Methods

This section is non-normative.

A WebID-CID Document MAY include verification methods as defined in [CID]. This enables cryptographic authentication without relying solely on OIDC.

{
  "@context": "https://www.w3.org/ns/cid/v1",
  "id": "https://alice.example/profile#me",
  "verificationMethod": [{
    "id": "https://alice.example/profile#key-1",
    "type": "Multikey",
    "controller": "https://alice.example/profile#me",
    "publicKeyMultibase": "z6Mkf5rGMoatrSj1f..."
  }],
  "authentication": ["https://alice.example/profile#key-1"],
  "service": [{
    "type": "OpenIdProvider",
    "serviceEndpoint": "https://idp.example/"
  }]
}

6. LWS Authentication Suite

This section sketches how WebID-based authentication might map onto the [LWS-PROTOCOL] authentication suite architecture, following the patterns in [LWS-AUTHN].

6.1. Suite Identifier

A WebID Authentication Suite could be identified by a URI such as:

https://www.w3.org/ns/solid/terms#Solid-OIDC

Authorization servers supporting this suite would advertise this URI in their subject_token_types_supported metadata field.

6.2. Token Claims Mapping

The WebID Authentication Suite maps LWS authentication requirements to [SOLID-OIDC] token claims:

6.3. Credential Validation

To validate an end-user credential in the WebID Authentication Suite:

1. Extract the webid claim from the ID Token

2. Dereference the WebID via HTTP

3. Parse the returned document (Turtle or JSON-LD)

4. Verify the iss claim matches a declared identity provider (in Turtle: <webid> solid:oidcIssuer <iss>; in JSON-LD/CID: service[type=OpenIdProvider].serviceEndpoint == iss)

5. Perform standard OIDC token validation using issuer’s published keys

7. Processing Requirements

7.1. Server Requirements

Under this model, an implementation hosting WebID 1.1 Documents would:

1. Respond to HTTP GET requests for the WebID

2. Support application/ld+json (JSON-LD) as the primary format

3. Optionally support text/turtle for backward compatibility

4. Return semantically equivalent content regardless of format (when multiple formats are supported)

5. Optionally use HTTP 303 redirects for fragment-less WebIDs per [WEBID-1.0]

7.2. Client Requirements

Under this model, a client processing WebID 1.1 Documents would:

1. Be able to parse JSON-LD format

2. Optionally parse Turtle format for backward compatibility

3. Send appropriate Accept headers indicating format preference

4. Extract identity provider information from the appropriate property based on format

5. Optionally cache documents respecting HTTP cache headers

8. Security Considerations

This specification inherits all security considerations from [WEBID-1.0].

Additional considerations for this approach:

Transport Security

WebIDs should use HTTPS in production environments.

Content Negotiation Attacks

Servers should ensure Turtle and JSON-LD representations are semantically equivalent to prevent attacks exploiting format differences.

CID Document Integrity

When serving as CID documents, WebID Documents could include verification methods to enable cryptographic proof of document integrity.

9. Privacy Considerations

This specification inherits privacy considerations from [WEBID-1.0].

WebID Documents MAY be segmented using rdfs:seeAlso or CID service endpoints to separate public and protected information.

10. Conformance

This section is non-normative.

As an exploratory draft, this document does not define formal conformance criteria. The following sketches what conformance might look like if this approach were formalized:

10.1. WebID 1.1 Server Conformance

A server following this model would:

1. Implement the behaviors described in § 7.1 Server Requirements

2. Serve valid [CID] documents when application/ld+json is requested

3. Serve valid [WEBID-1.0] documents when text/turtle is requested (if supported)

10.2. WebID 1.1 Client Conformance

A client following this model would:

1. Implement the behaviors described in § 7.2 Client Requirements

2. Correctly extract identity provider information from either format

10.3. LWS Authentication Suite Conformance

An implementation of a WebID Authentication Suite for LWS would:

1. Use a suite identifier (e.g., as sketched in § 6.1 Suite Identifier)

2. Map token claims as described in § 6.2 Token Claims Mapping

3. Perform validation as described in § 6.3 Credential Validation

11. Acknowledgments

This section is non-normative.

This specification builds on the foundational work of Henry Story, Tim Berners-Lee, and the WebID Community Group.

Thanks to Aaron Coburn for articulating the authentication suite pathway, Pavlik for framing WebID as HTTP binding, and the Linked Web Storage Working Group for the architecture enabling this integration.