From 731e0c5f0931ffec011930e5c31851f7da0d0524 Mon Sep 17 00:00:00 2001 From: Christoph Braun Date: Mon, 2 Mar 2026 18:45:05 +0100 Subject: [PATCH 01/19] initial draft --- lws10-ident-cid-http/index.html | 581 ++++++++++++++++++++++++++++++++ 1 file changed, 581 insertions(+) create mode 100644 lws10-ident-cid-http/index.html diff --git a/lws10-ident-cid-http/index.html b/lws10-ident-cid-http/index.html new file mode 100644 index 0000000..3d6deab --- /dev/null +++ b/lws10-ident-cid-http/index.html @@ -0,0 +1,581 @@ + + + + + + Linked Web Agent Identification: HTTP-based Controlled Identifier Profile + + + + + + + + +
+

+ HTTP URIs form the foundation of the Web. HTTP URIs are dereferenceable by any standard HTTP client without additional infrastructure. + This specification defines an HTTP-based Controlled Identifier [[CID-1.0]] Profile for Agent Identification in the Linked Web Storage Protocol [[LWS-CORE]]. +

+
+
+

+ This is an unofficial proposal. +

+
+ +
+

Introduction

+

+ HTTP URIs form the foundation of the Web. Importantly, HTTP URIs are dereferenceable by any standard HTTP client without additional infrastructure. + This specification defines an HTTP-based Controlled Identifier (CID) [[CID-1.0]] Profile for Agent Identification in the Linked Web Storage (LWS) Protocol [[LWS-CORE]]. +

+

+ The LWS Protocol [[LWS-CORE]] mandates the subject of authentication, i.e., an agent, to be identified by a URI [[URI]]. + LWS Authentication Suites, e.g., [[LWS-AUTHN-OPENID]],[[LWS-AUTHN-SAML]], or [[LWS-AUTHN-SSI-CID]], further recommend using a CID [[CID-1.0]] to this end. +

+

+ A CID is a URI. + Dereferencing a CID yields the CID document that may detail e.g. the CID's verification methdods or its controller. + An LWS Server would thus be able to obtain information, e.g, the agent's authentication key, that enables the LWS Server to authenticate the agent. + How exactly a CID is to be derefenced depends on the particular type of URI used as the CID, and remains unspecified by [[CID-1.0]]. +

+

+ To achieve interoperability of Linked Web Storages, it is required that LWS Servers are able to implement LWS Authentication Suites that might rely on dereferencing CIDs. + This in turn requires specifying a mechanism to dereference an agent's CID that LWS Servers can implement. + This specification provides one such mechanism, a mechanism based on HTTP [[RFC9110]] and the architecture of the Web itself [[WEBARCH]]. +

+ +

This specification is for:

+ + + +
+

HTTP-based CIDs allow a user to simply click on a CID they encounter on a Web page to obtain more information directly in their Web browser. +

+

LWS Use Case: LWS UCS #48

+
+ +
+

Terminology

+

+ This specification adopts terminology from [[LWS-CORE]] and [[CID-1.0]], including but not limited to: +

+
entity
+
as defined by [[LWS-CORE]].
+ +
controlled identifier document
+
as defined by [[CID-1.0]].
+
controller
+
as defined by [[CID-1.0]].
+
verification method
+
as defined by [[CID-1.0]].
+

Extracted from [[CID-1.0]] for easier reference:

+
subject
+
+ An entity, such as a person, group, organization, physical thing, digital thing, or logical thing that is referred to by the value of an id property in a controlled identifier document. +
+
base identifier
+
+ The value of the id property in the topmost map of the controlled identifier document is called the base identifier for the controlled identifier document. +
+
canonical URL
+
+ The URL for retrieving the current, authoritative controlled identifier document for a given identifier is called the canonical URL for the controlled identifier document. + Dereferencing the canonical URL MUST return the current authoritative controlled identifier document. +
+
+

+ +

+ This specification further defines the following terminology: +

+
agent
+
+ An agent is an entity that is able to initiate or perform actions, e.g., a person, an organisation, or a software application. +
+
agent identifier
+
+ An HTTP URI identifying an agent. +
+
+

+
+ +
+

Namespaces

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Prefixes and Namespaces +
PrefixNamespaceDescription
rdfhttp://www.w3.org/1999/02/22-rdf-syntax-ns# + [[RDF-SCHEMA]] +
rdfshttp://www.w3.org/2000/01/rdf-schema# + [[RDF-SCHEMA]] +
foafhttp://xmlns.com/foaf/0.1/ + [[!FOAF]] +
cidhttps://www.w3.org/ns/cid/v1# + [[CID-1.0]] +
+
+
+ +
+

Conformance

+

This section describes the conformance model of the Linked Web Agent HTTP-CID Profile.

+ +
+

Normative and Informative Content

+
+

All assertions, diagrams, examples, and notes are non-normative, as are all sections explicitly marked non-normative. Everything else is normative.

+

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

+

The key words “strongly encouraged”, “strongly discouraged”, “encouraged", “discouraged", “can", “cannot”, “could”, “could not”, “might”, and “might not” are used for non-normative content.

+
+
+ +
+

Specification Category

+
+

The Linked Web Agent HTTP-CID Profile identifies the following Specification Category to distinguish the types of conformance: notation/syntax, processor behavior, protocol.

+
+
+ +
+

Classes of Products

+
+

The Linked Web Agent HTTP-CID Profile identifies the following Classes of Products for conforming implementations. These products are referenced throughout this specification.

+ +
+
LWS Agent Document
+
A CID document that describes an agent identified by an HTTP URI.
+
Server
+
A Server that responds to HTTP requests to provide an LWS Agent Document.
+
Client
+
A Client that issues HTTP requests to obtain and process an LWS Agent Document.
+
+
+
+ +
+

Interoperability

+
+
+
Client–Server interoperability
+
+ Interoperability of implementations for Client and Servers is tested by evaluating an implementation’s ability to request, respond and process HTTP messages that conform to this specification. + Interoperability is achieved when a Client, given an agent identifier, can successfully obtain and validate the corresponding LWS Agent Document from any conforming Server, and thereby establish the authoritative binding between the agent identifier and LWS Agent Document, and subsequently, the agent's verification methods. +
+
+
+
+ +
+ +
+ +
+

Agent Identifier

+ +

+ An agent and an LWS Agent Document are two distinct resources [[WEBARCH]], which cannot be identified by the same URI at the same time. + This specification thus distinguishes between an LWS Agent Document's identifier and an agent identifier. + Importantly, the two identifiers denote different things: +

+

+ +

+ A Client can obtain the agent identifier's corresponding LWS Agent Document by dereferencing the agent identifier via HTTP [[RFC9110]]. + A Client then validates the corresponding LWS Agent Document to be indeed authoritative. +

+ +

An agent identifier SHOULD be an HTTP URI that includes a fragment [[!URI]].

+

+ When a Server receives an HTTP request targeting an agent identifier that does not include a fragment, the Server MUST respond with a redirect to the corresponding LWS Agent Document identifier in its Location header field. +

+ +
+ +
+

LWS Agent Document

+

+ An LWS Agent Document is a CID document; all property definitions by [[!CID-1.0]] apply. + In addition, this specification defines properties, restrictions, and examples provided in the following sections. +

+ +

+ An LWS Agent Document thus describes the verification methods of an agent. + It describes which verification methods might be used to make assertions about its primaryTopic, the agent. + Such assertions can be used as authentication credentials to authenticate the agent [[LWS-CORE]]. +

+ + +
+

Context

+

+ This specification mandates the strict inclusion of the @context property to ensure broad interoperability across implementations of Clients and Servers: +

+

+ An LWS Agent Document MUST specify JSON-LD's @context property to indicate the entire applicable context of the LWS Agent Document. +

+
+ + +
+

ID

+ +

+ The CID specification [[!CID-1.0]] defines the subject of a CID document to be identified by the CID document's base identifier which also MUST be the same as the canonical URL to retrieve the CID document from. +

+

+ This means that the URI identifying the subject is the same as the URL of the CID document. + When distinguishing between an agent and a CID document describing the agent, this then means that the subject of a CID document is the CID document itself. + The base identifier, the canonical URL of the CID document, cannot identify an agent at the same time. +

+

+ An LWS Agent Document MUST specify the id property to indicate the LWS Agent Document itself. +

+ +
+ + +
+

Primary Topic

+

+ An LWS Agent Document MUST specify the primaryTopic property to indicate the agent it describes [[!FOAF]]. + The value of the primaryTopic property MUST be different from the value of the id property. +

+
+ +
+

Controller

+

+ A controller of a CID document is capable of modifying the document's contents. +

+

+ An LWS Agent Document MUST specify at least one controller property to indicate any controller of the LWS Agent Document. +

+ + +
+ Examples of controllers include +
    +
  • the agent that is listed as the document's primaryTopic
    • +
  • an agent acting as a guardian of the agent that is listed as the document's primaryTopic, e.g., a parent of a child
    • +
  • a third party controlling the CID document, e.g., an Identity Provider
    • +
  • the entity exerting URI ownership [[WEBARCH]] of the CID
    • +
+ +
+ +
+ +
+

Verification Method

+

+ An LWS Agent Document might include one or more verification methods, e.g., for authentication or claim assertion, the choice of which depends on the particular protocols the agent takes part in. + See the CID specification [[CID-1.0]] for more details on verification relationships. +

+ +
+ +
+

Service

+

+ An LWS Agent Document might include one or more services, e.g., to express ways of communicating with the controller, or associated entities. + A service can be any type of service the controller wants to advertise for further discovery, authentication, authorization, or interaction. +

+ + +
+ +
+ +
+

Server

+
+

+ A Server MUST conform to HTTP Semantics [[!RFC9110]]. + A Server MUST use TLS connections through the https URI scheme in order to secure the communication with Clients. +

+

+ If a Server provides redirects from an agent identifier to a corresponding LWS Agent Document, then the Server SHOULD use a 303 status code and provide the URL of the LWS Agent Document in the Location header field. +

+ +

A Server MUST include a Content-Type header field in a message that contains content.

+
+ + +

Content-Negotiation

+

+ A Server MUST support content-negotiation for the media types of + application/cid [[!CID-1.0]], + application/json [[!JSON]], and + application/ld+json [[!JSON-LD]]. +

+

+ When serving a response based on content negotiation, a Server MUST include a Vary: Accept header field in the response to ensure proper caching behavior [[!RFC9110]]. +

+ +

Cross-Origin Resource Sharing (CORS)

+ +

A Server MUST support Cross-Origin Resource Sharing (CORS) [[!FETCH]].

+ +

+ Concretely, whenever a Server receives an HTTP request containing a valid Origin header [[!RFC6454]], + the server MUST respond with the appropriate Access-Control-* header fields as specified in the CORS protocol [[!FETCH]]. + In particular, the Server MUST set the Access-Control-Allow-Origin header field value to the valid Origin header field value from the request + and list Origin in the Vary header field value. + The Server MUST make all used response headers readable for the Client through Access-Control-Expose-Headers (with the possible exception of the Access-Control-* header fields themselves). + A Server MUST also support the HTTP OPTIONS method [[!RFC9110]] such that it can respond appropriately to CORS preflight requests. +

+ + + +
+ +
+

Client

+
+

A Client MUST conform to HTTP Semantics [[!RFC9110]].

+

A Client MUST use the Accept header field in a HTTP GET request to indicate acceptable media types for the requested LWS Agent Document [[!RFC9110]].

+
+ + + +

Dereferencing an Agent Identifier

+ +

+ If a Client does not expect a given HTTP URI to be an agent identifier, the Client derferences the URI as usual [[!RFC9110]][[!CID-1.0]]. +

+ +

+ If a Client expects a given HTTP URI to be an agent identifier, dereferencing that identifier is expected to yield its corresponding LWS Agent Document: +

+

+ + + + +
+

+ Whether or not a Client allows following redirects depends on the trust model assumed by the implementation: +

+

+
+ +

If a Client chooses to not follow redirects, then the Client MUST provide a client-defined error as the result of the process.

+ + + +

Validating an Agent Identifier against an Agent Document

+ +

+ A Client MUST reject a non-conforming LWS Agent Document and provide a client-defined error. +

+ +

+ In addition, a Client MUST verify that the value of the primaryTopic property for the LWS Agent Document matches the expected agent identifier, i.e., the exact URI inlcuding any fragment, + to validate that the obtained document is indeed authoritative for the given agent identifier. +

+ + + + + + + +
+ +
+

Security Considerations

+ +

+ As this profile is an application of the Controlled Identifier (CID) specification all security considerations defined in [[CID-1.0]] apply directly to this specification. +

+ +

+ The following HTTP-specific considerations also apply: +

+ + + +

+ This specification only provides one component to be used in an authentication, authorization, or more general, interaction protocol on the Web. + While composing such protocols is common-place in software engineering, it poses in inherent risk from a formal security perspective: + Composing a protocol from components that are individually sound does not entail that the resulting protocol is also sound. + To ensure desired security properties hold for the composed protocol, the authors of this specification strongly recommend making trust assumptions explicit and verifying the protocols' security properties using formal methods, e.g., following the approach presented in [[BHKM24]]. +

+
+ +
+

Privacy Considerations

+

+ As this profile is an application of the Controlled Identifier (CID) specification all privacy considerations defined in [[CID-1.0]] apply directly to this specification. +

+
+ +
+

Acknowledgements

+
+

Thanks to ...

+
+
+ + + \ No newline at end of file From 99241f14df0f71108aab266011dd57ba40867aa0 Mon Sep 17 00:00:00 2001 From: Christoph Braun Date: Mon, 9 Mar 2026 12:00:53 +0100 Subject: [PATCH 02/19] updated draft broadened scope and re-named directory --- .../index.html | 256 +++++++++--------- 1 file changed, 133 insertions(+), 123 deletions(-) rename {lws10-ident-cid-http => ident-cid-web}/index.html (63%) diff --git a/lws10-ident-cid-http/index.html b/ident-cid-web/index.html similarity index 63% rename from lws10-ident-cid-http/index.html rename to ident-cid-web/index.html index 3d6deab..6794bd7 100644 --- a/lws10-ident-cid-http/index.html +++ b/ident-cid-web/index.html @@ -3,7 +3,7 @@ - Linked Web Agent Identification: HTTP-based Controlled Identifier Profile + Web Agent Identification: A Web-based Controlled Identifier Profile (Web-CID) @@ -11,7 +11,7 @@ // See https://respec.org/docs/ for how to configure ReSpec var respecConfig = { specStatus: "ED", - shortName: "lws-ident-cid-http", + shortName: "web-cid", editors: [{ name: "Christoph Braun", company: "FZI Forschungszentrum Informatik", @@ -44,7 +44,7 @@

HTTP URIs form the foundation of the Web. HTTP URIs are dereferenceable by any standard HTTP client without additional infrastructure. - This specification defines an HTTP-based Controlled Identifier [[CID-1.0]] Profile for Agent Identification in the Linked Web Storage Protocol [[LWS-CORE]]. + This specification defines an HTTP-based Controlled Identifier [[CID-1.0]] Profile for Agent Identification on the Web.

@@ -57,67 +57,62 @@

Introduction

HTTP URIs form the foundation of the Web. Importantly, HTTP URIs are dereferenceable by any standard HTTP client without additional infrastructure. - This specification defines an HTTP-based Controlled Identifier (CID) [[CID-1.0]] Profile for Agent Identification in the Linked Web Storage (LWS) Protocol [[LWS-CORE]]. -

-

- The LWS Protocol [[LWS-CORE]] mandates the subject of authentication, i.e., an agent, to be identified by a URI [[URI]]. - LWS Authentication Suites, e.g., [[LWS-AUTHN-OPENID]],[[LWS-AUTHN-SAML]], or [[LWS-AUTHN-SSI-CID]], further recommend using a CID [[CID-1.0]] to this end. + This specification defines an HTTP-based Controlled Identifier (CID) [[CID-1.0]] Profile for Agent Identification on the Web.

A CID is a URI. Dereferencing a CID yields the CID document that may detail e.g. the CID's verification methdods or its controller. - An LWS Server would thus be able to obtain information, e.g, the agent's authentication key, that enables the LWS Server to authenticate the agent. - How exactly a CID is to be derefenced depends on the particular type of URI used as the CID, and remains unspecified by [[CID-1.0]]. + How exactly a CID is to be derefenced remains unspecified by [[CID-1.0]]. + It depends on the particular type of URI used as the CID.

- To achieve interoperability of Linked Web Storages, it is required that LWS Servers are able to implement LWS Authentication Suites that might rely on dereferencing CIDs. - This in turn requires specifying a mechanism to dereference an agent's CID that LWS Servers can implement. - This specification provides one such mechanism, a mechanism based on HTTP [[RFC9110]] and the architecture of the Web itself [[WEBARCH]]. + To achieve interoperability in CID-based agent identification and subsequent authentication on the Web, implementations of Clients and Servers require a common mechanism to dereference an agent's CID. + This specification provides one such mechanism based on HTTP [[RFC9110]] and the architecture of the Web itself [[WEBARCH]].

This specification is for:

HTTP-based CIDs allow a user to simply click on a CID they encounter on a Web page to obtain more information directly in their Web browser.

-

LWS Use Case: LWS UCS #48

+

Use Case: LWS UCS #48

Terminology

- This specification adopts terminology from [[LWS-CORE]] and [[CID-1.0]], including but not limited to: + This specification adopts terminology from [[CID-1.0]], including but not limited to:

-
entity
-
as defined by [[LWS-CORE]].
-
controlled identifier document
-
as defined by [[CID-1.0]].
-
controller
-
as defined by [[CID-1.0]].
-
verification method
+
controlled identifier document
as defined by [[CID-1.0]].
-

Extracted from [[CID-1.0]] for easier reference:

subject
-
+
as defined by [[CID-1.0]].
+
base identifier
-
- The value of the id property in the topmost map of the controlled identifier document is called the base identifier for the controlled identifier document. -
+
as defined by [[CID-1.0]].
+
canonical URL
-
- The URL for retrieving the current, authoritative controlled identifier document for a given identifier is called the canonical URL for the controlled identifier document. - Dereferencing the canonical URL MUST return the current authoritative controlled identifier document. -
+
as defined by [[CID-1.0]].
+ +
controller
+
as defined by [[CID-1.0]].
+
verification method
+
as defined by [[CID-1.0]].

@@ -126,11 +121,11 @@

Terminology

agent
- An agent is an entity that is able to initiate or perform actions, e.g., a person, an organisation, or a software application. + An agent is an entity that is able to initiate or perform actions, e.g., a person, an organisation, or a software application.
-
agent identifier
+
agent identifier
- An HTTP URI identifying an agent. + An HTTP URI identifying an agent.

@@ -174,7 +169,7 @@

Namespaces

cid - https://www.w3.org/ns/cid/v1# + https://www.w3.org/ns/cid/v1 [[CID-1.0]] @@ -186,7 +181,7 @@

Namespaces

Conformance

-

This section describes the conformance model of the Linked Web Agent HTTP-CID Profile.

+

This section describes the conformance model of the Web-CID Profile.

Normative and Informative Content

@@ -200,22 +195,22 @@

Normative and Informative Content

Specification Category

-

The Linked Web Agent HTTP-CID Profile identifies the following Specification Category to distinguish the types of conformance: notation/syntax, processor behavior, protocol.

+

The Web-CID Profile identifies the following Specification Category to distinguish the types of conformance: notation/syntax, processor behavior, protocol.

Classes of Products

-

The Linked Web Agent HTTP-CID Profile identifies the following Classes of Products for conforming implementations. These products are referenced throughout this specification.

+

The Web-CID Profile identifies the following Classes of Products for conforming implementations. These products are referenced throughout this specification.

-
LWS Agent Document
-
A CID document that describes an agent identified by an HTTP URI.
+
Web-CID Agent Document
+
A CID document that describes an agent identified by an HTTP URI.
Server
-
A Server that responds to HTTP requests to provide an LWS Agent Document.
+
A Server that responds to HTTP requests to provide an Web-CID Agent Document.
Client
-
A Client that issues HTTP requests to obtain and process an LWS Agent Document.
+
A Client that issues HTTP requests to obtain and process an Web-CID Agent Document.
@@ -227,7 +222,7 @@

Interoperability

Client–Server interoperability
Interoperability of implementations for Client and Servers is tested by evaluating an implementation’s ability to request, respond and process HTTP messages that conform to this specification. - Interoperability is achieved when a Client, given an agent identifier, can successfully obtain and validate the corresponding LWS Agent Document from any conforming Server, and thereby establish the authoritative binding between the agent identifier and LWS Agent Document, and subsequently, the agent's verification methods. + Interoperability is achieved when a Client, given an agent identifier, can successfully obtain and validate the corresponding Web-CID Agent Document from any conforming Server, and thereby establish the authoritative binding between the agent identifier and Web-CID Agent Document, and subsequently, the agent's verification methods.
@@ -237,54 +232,54 @@

Interoperability

-
+

Agent Identifier

- An agent and an LWS Agent Document are two distinct resources [[WEBARCH]], which cannot be identified by the same URI at the same time. - This specification thus distinguishes between an LWS Agent Document's identifier and an agent identifier. + An agent and a Web-CID Agent Document are two distinct resources [[WEBARCH]], which cannot be identified by the same URI at the same time. + This specification thus distinguishes between an agent identifier and an Web-CID Agent Document's identifier. Importantly, the two identifiers denote different things:

    -
  • An agent identifier is an HTTP URI identifying an agent [[!URI]].
    • -
  • An LWS Agent Document's identifier is an HTTP URI identifying the corresponding information resource [[!WEBARCH]], i.e., the document describing the agent.
    • +
  • An agent identifier is an HTTP URI identifying an agent [[!URI]].
    • +
  • An Web-CID Agent Document's identifier is an HTTP URI identifying the corresponding information resource [[!WEBARCH]], i.e., the document describing the agent.

- A Client can obtain the agent identifier's corresponding LWS Agent Document by dereferencing the agent identifier via HTTP [[RFC9110]]. - A Client then validates the corresponding LWS Agent Document to be indeed authoritative. + A Client can obtain the agent identifier's corresponding Web-CID Agent Document by dereferencing the agent identifier via HTTP [[RFC9110]]. + A Client then validates the corresponding Web-CID Agent Document to be indeed authoritative for the expected agent identifier.

-

An agent identifier SHOULD be an HTTP URI that includes a fragment [[!URI]].

+

An agent identifier SHOULD be an HTTP URI that includes a fragment [[!URI]].

- When a Server receives an HTTP request targeting an agent identifier that does not include a fragment, the Server MUST respond with a redirect to the corresponding LWS Agent Document identifier in its Location header field. + When a Server receives an HTTP request targeting an agent identifier that does not include a fragment, the Server MUST respond with a redirect and provide the corresponding Web-CID Agent Document identifier in the response's Location header field.

-

LWS Agent Document

+

Web-CID Agent Document

- An LWS Agent Document is a CID document; all property definitions by [[!CID-1.0]] apply. - In addition, this specification defines properties, restrictions, and examples provided in the following sections. + A Web-CID Agent Document is a CID document; all property definitions by [[!CID-1.0]] apply. + In addition, this specification defines properties, restrictions, and examples as follows.

-

- An LWS Agent Document thus describes the verification methods of an agent. +

+ A Web-CID Agent Document thus describes the verification methods of an agent. It describes which verification methods might be used to make assertions about its primaryTopic, the agent. - Such assertions can be used as authentication credentials to authenticate the agent [[LWS-CORE]]. + Such assertions can be used as authentication credentials, e.g., ID tokens [[OPENID-CONNECT-CORE]], SAML assertions [[SAML2-CORE]], or custom JSON Web Tokens [[RFC7519]], to authenticate an agent.

-

- Using distinct identifiers for the agent and their Web-CID Agent Document respectively allows expressing additional document-related meta data without ambiguity between the two. + Using distinct identifiers for the agent and their Web-CID Agent Document allows expressing additional document-related meta data without ambiguity between the two.