Propose Web-CID Profile for Agent Identification

[uvdsl]

This PR introduces an editor's draft for Web Agent Identification: A Web-based Controlled Identifier Profile (Web-CID).

The specification defines an HTTP-based mechanism to dereference an agent's CID for identification and subsequent authentication on the Web. It is designed to be highly interoperable by building directly on [CID-1.0], standard HTTP semantics [RFC9110], and the architecture of the Web itself [WEBARCH].

The specification's structure and conformance model is inspired by the Solid Protocol to
clearly define what constitutes conformance, to specify for testability, and to aim for interoperability.

Scope

The LWS protocol currently does not limit the mechanisms by which an agent (i.e., an authentication subject) may be identified. LWS Authentication Suites such as those based on OIDC or SAML might rely on CIDs to identify an agent. Other LWS Authentication Suites such as those based on did:key do not directly rely on CIDs.

This PR's proposal is deliberately broad in scope, as the proposed functionality is not limited to LWS Authentication Suites.
This proposal is useful for LWS in that it specifies a particular Web-based conformance model for CIDs that might be used in LWS Authentication Suites. This proposal might also be useful for non-LWS contexts, such as Web-based Verifiable Credentials. This is in-line with the modular design and layered architecture that both the LWS protocol and specifications around Verifiable Credentials adopt.

As the CID specification does not define how a CID is to be dereferenced, this proposal specifies one such potential mechanism for Clients and Servers to implement.

Intent

Following up on the discussion in #57, this draft is submitted for adoption by the WG for FPWD in the scope of LWS based on the action item assigned to me in the #lws meeting on 16 February 2026.

I am open to discussing the proposal at any depth and welcome feedback of any kind.
I further expect to iterate on specific sections, particularly Security and Privacy, to address standard horizontal review requirements (TAG/PING).

---

Preview (Original) | Preview (Current)

[elf-pavlik]

This may need to mention 303 redirect and maybe reference https://www.w3.org/TR/cooluris/#solutions

[elf-pavlik]

I see 303 as SHOULD in https://uvdsl.solid.aifb.kit.edu/spec/lws/ident-cid-web/draft.html#providing

[uvdsl]

Ah, yes. This might a slight editorial issue, indeed.

When a Server receives an HTTP request targeting an agent identifier,

• a Server MUST redirect.
• a Server MUST provide the URI/URL of the Web-CID Agent Document in the response Location header.
• a Server SHOULD use status code 303.

There might be valid use cases for using different status codes (301,302,307,308), which I did not want to exclude. To reflect that, the particular wording might need to be clarified or modified here.

---

Note that a Server might also only be configured in a way that only HTTP URIs that include a fragment are used as agent identifiers. In such a case, the Server does not need to redirect at all.

[elf-pavlik]

I don't understand why following 303 isn't a MUST. Publishing Web-CID with 303 redirect is a conformant way per this proposal. But then client is not required fully dereference valid Web-CIDs.

[uvdsl]

Publishing Web-CID with 303 redirect is a conformant way per this proposal.

Just because something is conformant does mean that it has to be mandatory.

I don't understand why following 303 isn't a MUST. [...] client is not required fully dereference valid Web-CIDs.

That is because following redirects is an implementation choice and depends on the trust model of the client. This is also in-line with HTTP itself [RFC9110].

[elf-pavlik]

Just because something is conformant does mean that it has to be mandatory.

If this spec defines interop I think requirements on interoperating parties have to match to ensure it. I think making following 303 redirects optional creates a mismatch and doesn't provide basic interop.

This is also in-line with HTTP itself [RFC9110].

Note

Automatic redirection needs to be done with care for methods not known to be safe, as defined in Section 9.2.1, since the user might not wish to redirect an unsafe request.

We are talking about GET which is a safe method.

[uvdsl]

The sentence before the one you cited is the normative one. A client MAY automatically follow redirects. And then, if a method is not safe, it should be careful.

In addition, the proposal is not limited to the HTTP GET method. So, no, we are not talking about (only) GET here.

[jacoscaz]

While I understand your point @uvdsl about redirect following not always being possible, I think pointing it out in this spec is more confusing than not. We can't possibly enumerate the entire space of issues that could originate from clients being unable to meet expectations, particularly when dealing with causes outside of their immediate control (i.e. a conformant client deployed in a network with a proxy that blocks 303s).

[elf-pavlik]

I couldn't find any HTTPRange-14 related discussion in CID repo and mailing list. Do you know if there were any prior conversations on this topics.
I think it would be good to also ask VC WG for feedback on this PR.

[acoburn]

Thank you @uvdsl for creating this proposal. I have left some in-line comments related to specific parts of the text. I also have some higher-level questions related to how this fits into the overall scope of the LWS protocol.

This proposal is interesting and I see how it combines many of the features of WebID and CID. I could see this as potentially being its own stand-alone document.

What I don't understand is how this fits into LWS. What requirement is this solving? What is currently not possible that these requirements clarify?

In the notes from the LWS WG Meeting on March 9, 2026 it is clear that the purpose of this document is not part of authentication. It is clear that identity is part of authentication, but our charter also explicitly lists "definition of new identity mechanisms" as out of scope.

Overall, I am unclear on what problem this is trying to solve and how that fits into the scope of LWS.

[acoburn]

This is clearly based on range-14 discussions, but why is it necessary to introduce that complexity here?

[uvdsl]

This proposal does not introduce this complexity - the complexity is inherent to identying non-information resources using HTTP URIs on the Web [WEBARCH]. This complexity is always conserved.

One might choose to ignore this complexity by punning HTTP URIs but this does not let this complexity vanish.

In our use cases, this complexity must be adressed. From consent-based data sharing, over authenticated access requests, to the more general data integrity verification, these all require our systems resource versioning and associtated provenance tracking -- which are both reflected in the LWS requirements of Resource Versioning and Auditable Trail. In these use cases, the resources in question are not only data resources stored on an LWS but also the agent documents (CID documents) to track which agent was able and allowed to authenticate with which keys, or at which point in time a particular controller was listed for an agent document.

Therefore, we must be able to identify an agent document (CID document) with a URI that is different from the identifier of the agent.

[angelo-v]

I agree with @uvdsl. Not differentiating both adds a lot more complexity in other places.

[kaefer3000]

I completely agree with @angelo-v - the complexity added by not differentiating is painful. I think about meta data here. @uvdsl points to already foreseen LWS use-cases where differentiating is important. The management in general of the documents and their provenance using meta data will be unnecessary complex if we do not make the difference between the identifier of the agent and the document.

[acoburn]

Why is this a MUST? In this context, a conforming server could support only GET operations and the Accept header, neither of which require CORS preflight requests.

[uvdsl]

Supporting CORS is not solely about handling preflight requests; it is fundamentally about the server authorizing the browser to expose the response data to a cross-origin web application. Even the simplest read-only API must opt-in to this cross-origin sharing in web applications via the HTTP response headers.

[elf-pavlik]

I assume we are talking about https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS#simple_requests

I would expect that someone in VCWG is using CID with HTTP. We could check if there have been any CORS issues with 'simple requests'.

[jeswr]

This proposal might also be useful for non-LWS contexts, such as Web-based Verifiable Credentials. This is in-line with the modular design and layered architecture that both the LWS protocol and specifications around Verifiable Credentials adopt.

I think this document is better suited to the VC WG should that group be willing to take it on.

cc @msporny for review and consideration of this document as a VCWG item

[msporny]

I think this document is better suited to the VC WG should that group be willing to take it on.
cc @msporny for review and consideration of this document as a VCWG item

The VCWG was just officially rechartered yesterday with a fairly heavy workload (20+ specs as deliverables!):

https://www.w3.org/2026/03/vc-wg-charter.html#deliverables

That group is already overloaded and is unlikely to recharter any time soon. That said, this thing could become a W3C Credentials Community Group work item, be incubated there, and then find it's way onto the standards track in another WG in the next year (as long as you can demonstrate momentum).

We do need to move the CID spec into a separate group, as well as the Data Integrity specifications (effectively work around "decentralized, linked data security"). There is a DID Methods WG that is waiting for a co-chair to get started, probably some time in the next six months:

https://w3c.github.io/did-methods-wg-charter/2025/did-methods-wg.html#deliverables

It is conceivable that this work would fit under that charter, but in order to get into that charter, you have to demonstrate some amount of incubation elsewhere (such as CCG). It is fairly simple to get a work item into CCG. Example here (just raise an issue on the CCG Github repo and send an intro email to the CCG mailing list):

w3c-ccg/community#255

Hope the above helps, if you are interested in pursuing that direction, @wip-abramson, @denkeni, and @mkhraisha (the CCG Co-Chairs) can help. /cc @iherman @pchampin @brentzundel and @philarcher (VCWG Chairs and W3C Staff) for visibility.

[uvdsl]

Hi @acoburn,
thank you for your review and for raising these high-level questions about scope.
I'd like to clarify exactly what problem this solves for LWS, and why the broader scope is a deliberate and necessary architectural choice.

Requirement

The core issue is this: While LWS authentication suites might rely on CIDs to identify agents, CID 1.0 explicitly leaves the dereferencing mechanism unspecified. If an LWS Authorization Server receives a token where the subject is a URI acting as a CID, how does it fetch the document to verify the cryptographic material?

Without a standardized dereferencing (e.g., HTTP as proposed) and validation mechanism (identifier-document validation, as proposed), LWS Servers are simply unable to implement CID-based authentication. "Just use HTTP URIs" does not suffice here: the choice of (a particular type of) URI comes with its own implementation details (as discussed in the individual comments here) and security and privacy considerations.

This is reflected in the fact that the CID specification is meant to be explicitly profiled (see CID Introduction and this issue). The lack of such profile directly prevents us from achieving the core Client-Server interoperability our charter mandates. This proposal specifies a CID application profile that is based on HTTP and the Web, as raised in #57 and assigned to me during the #lws meeting on 16 February 2026.

This is NOT a "New Identity Mechanism"

This proposal is an application profile of CID, and as such applies two existing standards (HTTP [RFC9110] and Controlled Identifiers [CID-1.0]. It simply defines the operational binding between them so that LWS (and other web protocols) can actually use them in practice.

Scope is Broad (And that is a Feature).

You are absolutely right that this document is written to be generally applicable to the Web, rather than being artificially siloed as an LWS-specific protocol quirk. This is intentional.

Our charter explicitly expects the Working Group to follow the TAG Web Platform Design Principles. One of the core tenets of Web architecture is modularization, i.e., building orthogonal specifications that solve specific problems well. By defining "Web-CID" generically, we solve our immediate LWS dereferencing problem while simultaneously being able to fulfil our charter's mandate to coordinate with e.g. the Verifiable Credentials Working Group and the WebID CG.

As @jeswr pointed out, this has utility for the VC ecosystem as well. I am completely open to discussing cross-group coordination (or even transferring it if the WG consensus goes that route, thank you @msporny for chiming in!), but the immediate dependency exists right here: LWS needs a standardized way to dereference Web-CIDs to ensure our own LWS authentication suites are actually implementable.

[pchampin]

@uvdsl first of all, I sympathize with the need to clarify what it means to "use CIDs with LWS" and or generally to "use CIDs with HTTP" -- noting that the latter does not encompass the former; I believe that we, or at least some of us, want LWS to be open to other kinds of URIs for identification, e.g. DIDs. But in any case, a clarifying document is welcome.

My biggest problem with this PR is the premise that we need to have two distinct URIs, one for the agent, and one for the CID document. You write in a comment above

An agent is a resource, a thing in the world. A document which describes the agent (its keys and verificaiton methods) is also a thing in the world. These two are distinct entities. And a URI can only unambiguously identify one of them at a time.

And I agree. But that does not entail that we need two distinct URIs. We can have a single URI, which would identify the agent, and which, when dereferenced, would yield the CID document, as a representation of the agent itself. In that scenario, we don't have a URI to talk about the document itself (just like any given representation of a content-negotiable resources does not always have a URI).

In fact, as you point out in your PR, this conflation of the agent's identifier and of the document's URL is required by the CID spec (CID, Section 2.1.1, the paragraph after Example 3). In your PR, you chose to diverge from this requirement, using id for the identifier of the document instead of the subject, and putting the URI of the subject in the newly introduced primaryTopic. I object to that divergence, and I claim that we can comply with Web Architecture and still follow that requirement of the CID spec, as explained above¹.

It seems to me that the need to define a normative profile of CID for HTTP CID primarily comes from this premise that you must diverge. If you drop that premise as I suggest, the role this document would change, but its utility would remain. Namely, it could be a WG Note clarifying how to interpret and use the CID spec and the HTTP spec together, in the light of Web Architecture. Such a note would be useful for LWS, and also have broader value. Most of the PR could be reused as is; in fact it contains very few original requirements, and as I wrote above, I believe that all of them are about "fixing" the conflation of agent URI with document URL.

Modulo this (admittedly big) adjustment, I support this PR.

Footnotes

1. Granted the CID spec is not entirely clear about that, and a property like controller fosters the confusion. Still, I believe that a webarch-compliant reading of the whole CID spec is possible. ↩

[uvdsl]

Thank you for your constructive feedback on this proposal, @pchampin!

I would like to clarify two points that seem to get conflated in this discussion. Pun intended 🙂

Distinction between agent and document / http-range-14 / punning HTTP URIs

I highlight that the discussion around this issue of http-range-14 has officially been put to rest, and the resulting advisement and decisions of the TAG is documented and explained in [COOLURIS] by the SWEO IG.

That said, I can absolutely follow the very RESTful reasoning that an agent's representation does not necessarily need to be identified at all. As I already said, one might ignore the complexity and pun HTTP URIs. But please, do acknowledge that this is not following the advisement that is the result of a very long and heated debate (that took place prior to my academic life, btw). I am merely following the advisement of TAG here, and I do acknowledge that others choose not to follow this advisement.

I must however insist that use cases exist (as laid out in my earlier comment), and have existed for a long time, and have been acknowledged by this WG. I would like to highlight that the advice of [COOLURIS] is indeed followed by many on the Web. I thus have to raise the very operational concern (especially by and for my affiliation) that the infrastructure and processes to address this issue have been in place for a decent 15+ years. I must thus insist that it must be further possible to identify agents as we are used to. It must be possible to identify an agent with an HTTP URI that includes a fragment AND it must be possible to identify an agent with an HTTP URI and provide a 303 redirect to the corresponding document. Don't break the Web.

I state for the record that this proposal is not reviving the issue again; it directly follows current best practices on the Web. The discussion around why punning HTTP URIs is not allowed by the current state of the proposal, initiated by others than me, is reviving the issue. I would prefer to stand on the shoulders of giants here. If the WG believes that reviving the issue is a good use of our time, then I am willing to take part in this discussion to ensure that past discussion and advisement is indeed taken into account.

This draft is a proposal that is intended to gather constructive feedback. Based on that feedback, I am absolutely willing to make this work for all of us.

What status this specification should have

As I laid out in my other earlier comment, the CID specification is meant to be profiled, as it does not sufficiently detail what must be implemented to ensure interoperability for a specific choice of (type of) URL. I maintain my position that "just use HTTP URIs" is insufficient guidance. I believe that a Group Note will boil down to exactly that. I believe we as a WG can do better.

HTTP-based agent identification has been incubated for years by the WebID CG and the Solid CG in form of [WebID], one of the input documents to this WG, . Using HTTP-based agent identification in agent authentication has been incubated by the Solid CG in form of [Solid-OIDC], one of the input documents to this WG and clearly an inspiration to [LWS-AUTHN-OPENID]. The corresponding agent document data model to enable agent authentication has been incubated by the Solid CG in form of [SOLID-WEBID-PROFILE]. All of the above is deployed across various use cases in the community, across academia, industry and public sector. Implementing the required modifications to adhere to this proposal is quite straight forward.

This proposal takes the existing W3C REC of CID to propose a data model that for agent documents that is in-line with the spirit of what has been incubated by the W3C CGs. If different communities require other needs to be reflected in this proposal, I am able and willing to coordinate with these communities, including the Solid CG (where I am one of the co-chairs, as is @elf-pavlik), the CCG and the VC WG, to progress both this proposal and CID if necessary to make this work for all communities interested in this proposal at W3C.

[jacoscaz]

IMHO, this very discussion perfectly represents the motivation and provides the necessary justification for this PR. This PR would not be necessary if one could understand how to direct implementational efforts towards producing conformant LWS servers and clients based on existing (draft) specifications alone with any reasonable amount of certainty that the result will achieve a basic level of interoperability.

The core issue is this: While LWS authentication suites might rely on CIDs to identify agents, CID 1.0 explicitly leaves the dereferencing mechanism unspecified. If an LWS Authorization Server receives a token where the subject is a URI acting as a CID, how does it fetch the document to verify the cryptographic material?

Exactly. Also, I find the effort to reconcile and incorporate past and present efforts truly admirable, all the way to http-range-14. My hat off to you, @uvdsl .

I maintain my position that "just use HTTP URIs" is insufficient guidance.

I can't stress enough how this is not just a position but a statement of truth for which there is uncountable evidence. Look at any of the specifications related to the transfer of information that enjoy true worldwide adoption and reach: Modbus, OCPP, HTTP, IMAP, SMTP, WebDAV, BACnet and countless others. I don't think you'll be able to find one that lacks what this PR tries to provide.

If the WG believes that reviving the issue is a good use of our time, then I am willing to take part in this discussion to ensure that past discussion and advisement is indeed taken into account.

This would be a very misguided use of our collective time. Speaking subjectively but from direct experience, the boundless revisitation of past decisions is one of the main causes that eventually brought the WebID CG to an end. Perfect is the enemy of good, as they say.

From what I can see, there's basically a conflict between COOLURIs and CID that makes the latter incompatible with the solutions proposed by the former. As engineers we need to find a way to reconcile the two. Given CID is less than 2 years old while COOLURIs has been around for 15+ years and assuming we want to optimise for interoperability, a minor deviation from CID sounds like a reasonable trade-off (ADDED: as long as it is clearly and explicitly acknowledged as such).

[acoburn]

HTTP-based agent identification has been incubated for years by the WebID CG and the Solid CG in form of [WebID], one of the input documents to this WG

As a point of clarification, our charter lists two input documents to this WG

• The Solid Protocol, version 0.11
• The Fedora API Specification 1.0

There are, in addition, several dependencies listed, including WebID. As stated in section 3.2 of the charter:

Depending on the Working Group progress, including consideration for adequate implementation experience, the Group may also decide to adopt the following dependencies as input documents

Yet there has been no decision to include WebID as an input document to the WG.

[aharth]

FWIW I agree with @uvdsl and others that "documents are not cars".

[kaefer3000]

I also agree with @uvdsl , and (Re: @aharth) to cite another pointed example from the days before the TAG decision on HTTP-Range-14 why making the difference is important: "Before I recommend the Vietnam War page, I have to be careful I am not recommending the Vietnam War". Note that the source of the quote pre-dates the TAG decision.

[uvdsl]

@laurensdeb thank you for putting this PR and my proposal on the agenda for the next meeting.
I should be able to join, looking forward to it.

@pchampin thank you, and much appreciated!

[w3cbot]

This was discussed during the #lws meeting on 30 March 2026.

View the transcript

PR #96 - Propose Web-CID Profile for Agent Identification

<laurens> w3c/lws-protocol#96

<gb> Pull Request 96 Propose Web-CID Profile for Agent Identification (by uvdsl)

laurens: Quite a bit of back and forth on #96 - want to keep it to 15 minutes for the agenda.

<gb> Pull Request 96 Propose Web-CID Profile for Agent Identification (by uvdsl)

<laurens> w3c/lws-protocol#57

<gb> Issue 57 Agent Identification (by uvdsl) [ready-for-pr]

uvdsl: To keep everything modular, came up with web based profile that LWS might employ. Have been extensive technical discussions - add to PR if needed. SHould it be recommendation track or working group note, or is this in scope.

laurens: My concerns at this point: most pressing are conflicts with auth suite, the subject plane (how to fix), extra effort needed by implementors to take into account (range 14 concerns), Structure of LWS protocol - I don't see a good fit how this spec ties into the other documents - not sure its best for implentors

<uvdsl> w3c/cid#164

<gb> Issue 164 Base identifier including a fragment (by pchampin)

uvdsl: On tech aspects, proposal not set in stone. pchampin has locked issues upstream, has been discussion with verifiable identity group - can update as needed. We can drop the workaround if there is a more elegant solution for the agent vs subject. Current proposal is best way right now I could solve the various issues. This does not adhere
… to one protocol construct with LWS, but LWS could still potentially use it. Verifiable Credential group uses a modular spec that might work for us too.

pchampin: I'm abivalent to pushing this as a separate track document, my main reason is that apart from reconciliation, a smoother alignment is needed and already possible. My impression is just do what is in the other spec - not sure about that. Maybe is should be guidance instead

<Zakim> uvdsl, you wanted to answer PAC

<pchampin> my point was: if you want to use https: CIDs, do whatever the CID spec says *and* what the HTTP spec says

uvdsl: I do agree with a smoother reconciliation. The CID spec does not require http scheme, as such, don't define conformance statements about how to serve the control document. There is an unspecified implementation gap, so I propose the LWS will provide the implementation spec in addition to the CID requirements that don't include
… implementation. We need a normative document to specify servers/consumers for this conformance profile of CID

<Zakim> acoburn, you wanted to describe current technical conflicts and outline possible paths forward

acoburn: I object to this beacause of specific technical conflicts between CID spec and LWS spec. THis make it a bit of a non-starter. CID specifies a particular id field as being subject being described (in oauth etc) and that the subject is not the agent but the document id. We could take an alternative approach: lets us adhere to CID and stay
… consistent to LWS/oauth subject, simply describe how an implementation would differentate between agent and document url.

<pchampin> +1 303 redirect is the "currently available smoother reconciliation" that I was talking about earlier

<Zakim> uvdsl, you wanted to respond to acoburn

acoburn: I'm pretty strongly -1 on this proposal, but there are ways to achieve the CID goals in a different way

<uvdsl> w3c/lws-protocol#96 (comment)

<gb> Pull Request 96 Propose Web-CID Profile for Agent Identification (by uvdsl)

<uvdsl> w3c/cid#163

<gb> Issue 163 Clarification about canonical URL dereferencing (by pchampin)

uvdsl: my proposal does not diverge from CID - usage of terms in different context is not indicative of the entire proposal - it is acceptable to clearly define the semantic differences in different speciations with the terminology section. I suggest pchampin's path to reconcile differences, redirect might cause a problem, but might be issues
… between canonical url of document and redirect does not resolve the underlying problem of fragment identifier. 303 has faced quite a resistance in the past so careful to recommend that as a solution. I would prefer pchampins approach

<Zakim> pchampin, you wanted to agree with both uvdsl and acoburn

pchampin: I agree with both uvdsl and acoburn. Yes a CID can have itself as a subject, but then the expectation in rest of auth suite is that the subject is the agent. Proposal conflicts with general approach to oauth. But I see that you want a smoother approach. As for 303, its not to require 303, I would argue that its not the easiest way to

comply (given the discomfort), but its the only way to comply at the moment. I think its viable to use this now.

gibsonf1: at Twinpod, we do 303 redirect, it is a little ackward but it works
… we don't use fragments in WebID

<Zakim> acoburn, you wanted to say that http14 should be possible, not required

acoburn: It should be possible to satisfy range 14, but it should not be required

<uvdsl> Using other CID profiles is always possible :)

<pchampin> I would consider that they conflict with how other specifications are typically articulated with each other

laurens: To summarize: proposal has some conflicts both inside and outside this working group. On the other hand, there are range 14 concerns, with 303 redirect a possible solution, and possible CID 1.1 which might support fragment identifiers. Does that summarize it for you and do you see a path forward?

uvdsl: I would propose to adopt WEB-CID as a work item

laurens: any text to propose a vote on that

<uvdsl> I thus propose Web-CID, an HTTP-based conformance profile for agent identification on the Web, for adoption by the WG as FPWD. This delivers on the task I was already assigned by the chairs to contribute to clearing issue #57 .

<gb> Issue 57 Agent Identification (by uvdsl) [ready-for-pr]

laurens: any objections?

<laurens> PROPOSAL: To adopt Web-CID, an HTTP-based conformance profile for agent identification on the Web, as proposed in PR #96

<gb> Pull Request 96 Propose Web-CID Profile for Agent Identification (by uvdsl)

<pchampin> +0

<uvdsl> +1

<laurens> -1

<acoburn> -1 (for the reasons outlined in the meeting)

<kaefer3000> +1

<bendm> +0

<TallTed> -0

<gibsonf1> +0

<ryey> +0 (have no enough knowledge to determine)

<eBremer> +0

<jeswr> +0

laurens: Because of the -1's, we need to remove the conflicts with LWS first. We are running low on time to finish our charter

<Zakim> uvdsl, you wanted to ask about the specific conflicts

laurens: There is relevance to this proposal and the discussion, would like to remove conflicts prior to merge.

uvdsl: Could you summarize the conflicts so I can address them?

laurens: Most important is validation of authentication credentials.

uvdsl: Would have been good to get this feedback earlier

---

[laurensdeb]

@uvdsl As discussed during the WG Meeting of March 30th, 2026, there are a couple of issues which are currently blocking this PR from getting approved.

Notably following concerns should be addressed first:

• Contradictory definitions with LWS Core protocol and Authentication Suites*: The “sub” claim is currently defined as an “agent identifier” in the core protocol and authn suites. Whereas the “foaf:primaryTopic” is defined as the agent identifier in your PR.
• Validation algorithm conflicts with agent and document identifier separation: “The resulting resource MUST be formatted as a valid controlled identifier document [CID-1.0] with an id value equal to the subject identifier.” (Ref)
• Conflicting definitions with CID and DID specification: Both the CID (and DID) specifications define the subject of the identifier as being “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”, such that this specification redefining this property to be the identifier of the document creates a conflict between the two. I don’t think it is in our best interest to redefine terminology in such a way, in particular when this could call for objections during the review process after CR. Note also that the terminology section currently references the CID definitions.
• Normative statements are made in a note: This is mostly editorial, with regards to the MUST in this section.

As suggested during the WG call I would recommend to document the use of 303 redirects as a solution to the HTTP Range 14 concerns in a non normative way instead of the fragment identifier approach, at least until the issues @pchampin raised in the CID specification repo get resolved at some point in the future and fragment identifiers would be allowed in CID subjects.

@acoburn Do you have any additional concerns?

[acoburn]

My main concern about this proposal is that there is a conflict between how "subject" is defined by CID and how this proposal uses "subject".

Specifically, per CID (1.4 Terminology):

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. Subjects identified in a controlled identifier document are also used as a subjects in other contexts, such as during authentication or in verifiable credentials.

Also, per CID (2.1.1 Subjects):

A subject is expressed using the id property in a controlled identifier document. The value of an id property is referred to as an identifier.

Per this proposal (section 3.2 ID), the subject of a CID is not an entity such as a person, group, organization, physical thing, digital thing, or logical thing; rather

A Web-CID Agent Document MUST specify the id property to indicate its own identifier.

In other words, this proposal restricts a CID document such that the subject of a CID is the CID document itself and not some external entity. This is inconsistent with every use case described in the CID specification and with how CID is used by existing external specifications, such as DID and Verifiable Credentials.

If this proposal relies on an unconventional understanding of "subject", then I would suggest that this proposal need more incubation and is not ready for a W3C working group.

[uvdsl]

@laurensdeb, @acoburn, thank you for spelling out your concerns more concretely. I appreciate your feedback on this proposal. To better understand your concern on the notion of "subject", could you clarify your statement

Per this proposal (section 3.2 ID), the subject of a CID is not an entity such as a person, group, organization, physical thing, digital thing, or logical thing;

as to how in your opinion a Web-CID Agent Document is not a "digital thing"?

[TallTed]

I'm not sure this does the job. Adjustments welcome.

Suggested change

	This risk can be mitigated by a <a href="#Client">Client</a> by not following redirects, which means to only accept <a href="#agent-identifier">agent identifiers</a> that include a fragment [[URL]].
	This risk can be mitigated by a <a href="#Client">Client</a> not following redirects, meaning that it will only accept <a href="#agent-identifier">agent identifiers</a> that include a fragment [[URL]] and that do not dereference to a `3xx` HTML result.

[uvdsl]

Thank you, @TallTed, for this suggestion as well as all the others! Much appreciated!

Maybe something along the following lines?

Suggested change

	This risk can be mitigated by a <a href="#Client">Client</a> by not following redirects, which means to only accept <a href="#agent-identifier">agent identifiers</a> that include a fragment [[URL]].
	This risk can be mitigated by a <a href="#Client">Client</a> by not following redirects. Such Client will only accept <a href="#agent-identifier">agent identifiers</a> that include a fragment [[URL]] and that do not result in a redirect upon dereferencing.

[TallTed]

Small (I think) tweaks needed to your suggestion, @uvdsl. What do you think of this?

Suggested change

	This risk can be mitigated by a <a href="#Client">Client</a> by not following redirects, which means to only accept <a href="#agent-identifier">agent identifiers</a> that include a fragment [[URL]].
	A <a href="#Client">Client</a> can mitigate this risk by not following redirects (e.g., HTTP/S `3xx` result codes). Such a Client will only accept an <a href="#agent-identifier">agent identifier</a> that includes a fragment [[URL]] and that does not result in a redirect upon dereferencing.

[uvdsl]

I think a second "by" sneaked in there: "[...] risk by by not following [...]"
Otherwise, yes, that works for me!

[TallTed]

Updated suggestion. Nice catch.