Agent Identification

[uvdsl]

Following @pchampin's encouragement, I would like to bring forward the following thoughts, based on a related discussion in the Solid CG on CID and WebID.

• The Solid Protocol and the Fedora API Specification (via WAC) adopt WebID 1.0 to identify agents.
• To my current understanding, LWS will adopt Controlled Identifiers (CIDs), a W3C Recommendation, to enable agent authentication.

I believe CIDs and WebIDs to be complementary. I don't think they are substitutes

---

WebID is primarily concerned with identification and thus defines a WebID as a HTTP URI that identifies an agent. The WebID specification defines that upon dereferencing the WebID, thus using HTTP, yields the corresponding WebID profile document.

Controlled Identifiers are primarily concerned with providing means of authentication and to this end defines a CID as a URI that identifies the CID subject (and simultaneously the CID document, as I read the description). The CID specification does not define the transport protocol or how a CID document is to be obtained.

There are technical reasons not to discard WebIDs prematurely:
Given that the current Solid Protocol and the entire Solid ecosystem relies on WebIDs, I deem it insufficient to simply propose to adopt a specification (even if it is already a REC), without at least considering purpose and usefulness of respective specifications. WebIDs are able be the missing piece from the CID specification for Solid: WebIDs identify agents and dereference via HTTP to their profile documents. These profile documents then could adhere to the CID specification such that authentication of the agents identified by their WebIDs is possible.

In my mind, CIDs do not replace WebIDs. The CID-proposed data model replaces how Solid-OIDC is currently advertised in a WebID profile using <webid> solid:oidcIssuer <idp>.. When adopting the CID specification and re-using a WebID as subject, a WebID just becomes a CID.

---

As I pointed out in the LWS protocol issues ([1], [2]), I believe there is value in clearly describing a protocol without flexibility for flexibility's sake.

I understand that the LWS Protocol specification cannot normatively reference the WebID specification as it only a Draft Community Group Report. I wonder, however, whether it would be worth at least to consider bringing the/a WebID specification to REC within the scope of this WG: Similar to how the LWS Protocol provides a normative out-of-the-box REST "binding" for the generic CRUD operations, the LWS Protocol could also provide an out-of-the-box REST "binding" to identify an agent.

[acoburn]

There is, indeed, a significant history with WebID and Solid. And, as is already pointed out, the LWS WG cannot normatively reference a draft CG report.

It is also important to note that using WebID as an authentication mechanism is not incompatible with the current LWS authentication requirements.

In fact, the LWS authentication requirements are very generic:

1. agents MUST be identified with URIs
2. an authentication suite MUST be identified with a URI
3. an authentication suite MUST define a mechanism for validating a token

This results in a variety of "Authentication Suites", one of which uses Controlled Identifier Documents with OpenID Connect. There are other defined suites in the LWS draft: did-key, saml, and ssi-cid.

The Solid CG would be in an excellent position to write a WebID Authentication Suite for LWS, since the constraints that exist for a WG do not all apply to a CG. And in fact, the LWS requirements were written in such a way that it would be possible for someone to write a conforming WebID authentication suite.

Here is what you would need for such a suite:

1. Define a URI to identify the authentication suite. An example might be: https://w3.org/ns/solid/terms#Solid-OIDC. Any supporting authorization server would advertise this URI in the subject_token_types_supported metadata field.
2. Define how, in this authentication suite, the fields for agent id, client id, issuer and audience restriction map to a token. If the suite follows the Solid-OIDC guidance, this would involve using a JSON Web Token with the following claims webid (for subject identifier), azp (for client identifier), iss (for issuer) and aud (for audience restrictions).
3. Define how an authorization server would validate such an incoming token. This definition would just copy from or reference the Solid-OIDC CG spec.

In short, it should be entirely possible to continue to use WebID-based identity with LWS, provided that a given implementation supports that authentication suite.

[elf-pavlik]

@uvdsl: WebIDs are able be the missing piece from the CID specification for Solid: WebIDs identify agents and dereference via HTTP to their profile documents. These profile documents then could adhere to the CID specification such that authentication of the agents identified by their WebIDs is possible.

@acoburn: The Solid CG would be in an excellent position to write a WebID Authentication Suite for LWS, since the constraints that exist for a WG do not all apply to a CG.

I'm looking at https://w3c.github.io/lws-protocol/lws10-authn-openid/ and I'm trying to understad

• What missing pieces need to be added to this draft that WebID could provide
• Does WebID AuthN have to be an alternative to the draft above and what technical advantages would it have, I understand certain familiarity and continuity but besides that why would people adopting it in a year or two choose it?

EDIT I would love to see conformance tests for both and see how they differ and what exactly implemenations need to do differently to be conformant and operational.

[acoburn]

@elf-pavlik the key part of https://w3c.github.io/lws-protocol/lws10-authn-openid/ is that, during verification, when an agent identifier is dereferenced, that resource MUST be a Controlled Identifier document, not a WebID profile.

Specifically, the resulting data MUST be JSON-LD, not Turtle.

There is also a way that both WebID (for traditional Solid servers) and Controlled Identifiers (for LWS servers) can be simultaneously supported. Provided that the WebID server can support content negotiation, it could produce TURTLE when requested (Accept: text/turtle):

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

<https://alice.example/id>
    a       foaf:Person ;
    pim:storage <https://storage.example/> ;
    solid:oidcIssuer <https://openid.example> .

An equivalent CID document (Accept: application/cid):

{
    "@context": [
        "https://www.w3.org/ns/cid/v1",
        "https://context.example/v1"
    ],
    "id": "https://alice.example/id",
    "type": ["Person"],
    "storage": [{
        "id": "https://storage.example/"
    }],
    "service": [{
        "type": "https://www.w3.org/ns/lws#OpenIdProvider",
        "serviceEndpoint": "https://openid.example"
    }]
}

The CID example assumes that Person and storage are defined in the example context.

[elf-pavlik]

Personally I see current adoption of Soild, even broader WebID as very limited and at least for me backward compatibility isn't a major goal. That's why I asked what someone adopting it in let's say 2 years would choose, implicitly assuming that in that bright future adoption would be at least an order of magnitude greater than today.

@uvdsl doesn't even mention media types, but I read more focus on HTTP and from prior conversations I recall reference to (dreaded?) httpRange-14

[melvincarvalho]

As someone who has participated in the WebID Community Group throughout its later phases, I wanted to add some historical context that may be useful here.

During 2023–2024, the WebID CG reached rough consensus that decisions around serialization, vocabulary, and final form should be handled in a Working Group, rather than resolved within the CG itself. A key reason was exactly the issue raised here: CG-level specifications cannot be normatively referenced by WGs, which limits their usefulness in downstream standards.

This view was expressed explicitly on the public-webid list. Henry Story (WebID CG Chair and original WebID author) noted in July 2023 that

“we would need consensus on the vocabularies to use, and without a WG process, I don't see we can reach that point”

and that integration via a WG was the appropriate next step (mailing list, July 2023).

In February 2024, I also noted on the list that there was emerging agreement to transition the WebID Editor’s Draft to a WG path where it could realistically progress to Recommendation (mailing list, Feb 2024). The CG was subsequently paused in July 2024 during this period of transition and uncertainty, rather than due to lack of interest or relevance.

From that perspective, if the LWS WG were interested in adopting WebID as a deliverable, it would be broadly consistent with the direction the CG was already heading. I’m happy to provide additional historical context or help coordinate if useful.

[elf-pavlik]

we would need consensus on the vocabularies to use

https://www.w3.org/TR/cid/#contexts-and-vocabularies

CID seems to alerady be taking care of it, I would also note in the initial comment

In my mind, CIDs do not replace WebIDs. The CID-proposed data model replaces how Solid-OIDC is currently advertised in a WebID profile using solid:oidcIssuer .. When adopting the CID specification and re-using a WebID as subject, a WebID just becomes a CID.

So if VC WG already solved vocabs problem, what else still would need to go through a WG?

again from theinitial comment

Controlled Identifiers are primarily concerned with providing means of authentication and to this end defines a CID as a URI that identifies the CID subject (and simultaneously the CID document, as I read the description). The CID specification does not define the transport protocol or how a CID document is to be obtained.

Emphasis is mine. At the end there's also

I understand that the LWS Protocol specification cannot normatively reference the WebID specification as it only a Draft Community Group Report. I wonder, however, whether it would be worth at least to consider bringing the/a WebID specification to REC within the scope of this WG: Similar to how the LWS Protocol provides a normative out-of-the-box REST "binding" for the generic CRUD operations, the LWS Protocol could also provide an out-of-the-box REST "binding" to identify an agent.

Currently my understanding, which I hope @uvdsl could further clarify, is that:

• WebID IS NOT needed for Turtle serialization
• WebID IS NOT needed for some specific vocabulaires
• WebID IS NOT needed to define alternative OIDC AuthN suite
• WebID IS needed for HTTP binding similart to REST binding for CRUD in current LWS draft.

the key part of https://w3c.github.io/lws-protocol/lws10-authn-openid/ is that, during verification, when an agent identifier is dereferenced, that resource MUST be a Controlled Identifier document, not a WebID profile.

@acoburn in https://w3c.github.io/lws-protocol/lws10-authn-openid/#serialization

The ID Token MUST use the sub (subject) claim for the LWS subject identifier.

Would it be conformat to use a https://keri.one/ to denote LWS subject? For example did:keri:EXq5YqaL6L48pf0fu7IUhL0JRaU2_RxFP0AL43wYn148

[melvincarvalho]

Following the discussion on WebID as an HTTP binding for CID, I put together a small exploratory draft to help ground the conversation in something concrete:

https://melvincarvalho.github.io/webid11-draft/

The intent here is not to propose a standard, but to explore one possible way the pieces might fit together, building on existing WebID practice, the LWS WG's authentication suite architecture, and the framing raised in this thread. In particular, the draft:

• treats WebID as a possible HTTP binding where CID leaves details unspecified (responding to @elf-pavlik’s framing),
• explores a JSON-LD–based approach with backward compatibility for existing Solid deployments,
• sketches how WebID-based authentication might map onto emerging LWS requirements,
• and shows how content negotiation could allow a single WebID to serve both LWS-oriented and legacy clients.

This is a personal, unofficial draft, based on my experience with WebID since its early days, shared purely to support discussion and experimentation. If useful, I hope it can help inform thinking in both the WebID and LWS contexts, rather than pre-empt any particular outcome.

Repo: https://github.com/melvincarvalho/webid11-draft

Feedback very welcome.

[acoburn]

@elf-pavlik

Would it be conformat to use a https://keri.one/ to denote LWS subject? For example did:keri:EXq5YqaL6L48pf0fu7IUhL0JRaU2_RxFP0AL43wYn148

Reiterating the LWS requirements for authentication, there are three aspects: the subject identifier needs to be a URI. This is already true here.

The second requirement involves using a subject token identifier when exchanging the credentials for an access token. Here, one can either reuse an existing, defined authentication suite URI or create a new one.

Third, if you choose to reuse an existing suite, e.g., the OpenID connect suite, then the only additional requirement is that the verifying entity (i.e., the authorization server) is able to resolve the keri identifier as a CID document. Any additional verification requirements of the suite apply.

Alternatively, you could define a new authentication suite, where the verification rules are defined in that suite itself.

[elf-pavlik]

Third, if you choose to reuse an existing suite, e.g., the OpenID connect suite, then the only additional requirement is that the verifying entity (i.e., the authorization server) is able to resolve the keri identifier as a CID document. Any additional verification requirements of the suite apply.

What's the strategy to ensure that in practice? Is there intent to require additional layer on top of OpenID connect suite which would mandate support for specific schemes / DID methods and resolution mechanisms? For example HTTPS.

In #57 (comment) you suggested an alternative to LWS OIDC suite, rather adding a layer (even just few requirements) on top of it.

---

@melvincarvalho looking at https://github.com/melvincarvalho/webid11-draft/commits/gh-pages/
Did you hand craft it or used LLM to generate it? If later could you please add session(s) to the record somewhere in your repo.

I would be cautious with adding to much complexity, instead aim to keep it simple (less is more). If current LWS OIDC suite lacks clear HTTP binding. Adding it should be very simple, possibly a section with just few requirements or a tiny (few short paragraphs) separate spec.

When it comes to historical WebID - a CG report, compatibility / migration strategy could be addressed separately and only required for those who have old systems to deal with. I believe there will be a dedicated WG NOTE on Solid - also CG report, compatibility / migration. I think any decisions should probably be made based on real world data of how many actively used systems / user bases are affected by those decisions. I don't want to drift into that in this issue. I think there could be a dedicated venue to gather that real world data and have conversations about burdens and frictions related to various approaches.

[acoburn]

@elf-pavlik in general, for an authentication suite such as lws-oidc, I would not expect a verifier to support arbitrary did methods. If an implementor wants to support specific did methods, the best approach would be to define an authentication suite such as the one for lws-did-key.

I will also note that this discussion has drifted from the original topic. If you would like to continue discussing authentication mechanisms for particular did methods, please open a separate issue.

Please also note that -- and this applies to both the WebID and DID conversations -- the WG already has a roadmap of topics that will likely fill the remainder of the current charter. Discussing potential work items in the context of a possible future (re-chartered) WG is one thing. Discussing adding work items to the scope of the existing charter would mean dropping one or more items from the current roadmap.

[elf-pavlik]

@elf-pavlik in general, for an authentication suite such as lws-oidc, I would not expect a verifier to support arbitrary did methods. If an implementor wants to support specific did methods, the best approach would be to define an authentication suite such as the one for lws-did-key.

I think comparing those two can be a better example but https://w3c.github.io/lws-protocol/lws10-authn-openid/#serialization
has almost exact the same sub definition except s/JWT/ID Token/

https://w3c.github.io/lws-protocol/lws10-authn-ssi-cid/#serialization

The JWT MUST use the sub (subject) claim for the LWS subject identifier.

https://w3c.github.io/lws-protocol/lws10-authn-ssi-did-key/#serialization

The JWT MUST use the sub (subject) claim for the LWS subject identifier. The subject identifier MUST use a did:key: URI.

So for operational interop, where conformant implementations MUST implement https: subject identifiers.
The JWT MUST use the sub (subject) claim for the LWS subject identifier. The subject identifier MUST use a https: URI.

One has to copy&paste the whole lws10-authn-ssi-cid and just

- The JWT MUST use the sub (subject) claim for the LWS subject identifier.
+ The JWT MUST use the sub (subject) claim for the LWS subject identifier. The subject identifier MUST use a `https:` URI.

?

Speaking of copy&paste https://w3c.github.io/lws-protocol/lws10-authn-ssi-cid/
has title LWS Authentication Suite: OpenID Connect and [OPENID-CONNECT-CORE] as informative reference

[melvincarvalho]

Quick question: how do fragment identifiers (e.g. #me in WebID) work with CID's requirement that document id equals the canonical URL?

[TallTed]

I believe CIDs and WebIDs to be complementary. I don't think they are substitutes

As a member of the WGs that formulated both CIDs and DIDs, as well as the CG that produced the draft report on WebIDs, I believe I can say definitively that CIDs and WebIDs are not complementary, nor is one a substitute for the other.

Rather, WebIDs and DIDs are both subcategories, a/k/a subclasses, of CIDs.