Issue posted — memory / state / provenance as a missing piece

The shortest framing: we have spent thirty years building a web that
  transmits documents. The next decade asks for a web that accumulates
  belief.

  What "belief" means here, in plain terms:

    - A proposition — an abstract statement that could be true or false
    - Carrying evidence — claims from identifiable sources that bear on it
    - With provenance — which source, what time, what independence
    - Composing across sources — multiple voices, sometimes contradictory
    - Updating as new evidence arrives, without erasing what came before

  A web of pages stores statements. A web of belief stores the whole
  shape — the statement, the evidence chain, the disputes that contest
  it, the confidence as new evidence arrives, the lineage that lets a
  regulator, an operator, or another agent ask "how did we come to
  think this, and is it still true?"

  Two design choices distinguish what I have been working with:

    1. It is a hypergraph, not a tree. A single piece of evidence can
       bear on several propositions at once. A single source's
       reputation propagates through every claim they make, all at
       once. Disputes form structural counter-nodes rather than negative
       votes that collapse into majorities.

    2. It is distributed, not central. No registry decides what is
       believed. Each publisher hosts their own belief journal at their
       own URI or DID. Beliefs from different publishers reference each
       other across the open web, the same way pages have always
       referenced pages.

  Those two together are why I think this matters at the scale of the
  web rather than at the scale of one CG draft.

  A web that can accumulate, dispute, and audit — not just transmit —
  is what the next generation of agent infrastructure is going to need
  under it, whether that infrastructure is built in public-interest
  standards venues or built by three vendors behind closed APIs. The
  EU AI Act, the regulatory frameworks coming after it, and the audit
  expectations that follow them are converging on the same answer: a
  claim made by a system needs to carry its lineage with it, in a form
  that doesn't depend on the goodwill of the system's vendor.

  What I am not claiming, and want to be explicit about:

    - I am not claiming the specific shape in the working note is the
      right one. It is one shape; the CG should evaluate.
    - I am not claiming this displaces existing W3C work. RDF, Linked
      Data, Verifiable Credentials, DIDs — the substrate has been
      accumulating for two decades. What this gap asks for is a thin
      layer above that substrate, not parallel to it.
    - I am not claiming this needs to live exclusively here. If part
      of it belongs in the VC WG, the Agent Identity Registry CG, or
      the RDF & SPARQL WG, those are the right venues for those parts.

  What I am claiming: the gap is real, the shape is workable, the
  window for keeping this in a public-interest standards space rather
  than ceding it to vendor protocols is short, and the people most
  qualified to fill the gap are open-source maintainers and implementers
  already running this kind of substrate in production. This community
  has the right composition for that work.

  The working note is a sketch. The issue is an invitation. I would
  welcome reactions — including ones that reframe, redirect, or send
  the work elsewhere.

  [1] https://github.com/w3c-cg/ai-agent-protocol/issues/36
  [2]
https://github.com/Recursive-Emergence/bella/blob/main/docs/w3c-agent-protocol-notes.md

  — Isaac Mao
     github.com/immartian
     W3C profile 176969
  — Isaac Mao

On Mon, May 25, 2026 at 10:29 AM Aaron Parecki <aaron@parecki.com> wrote:

> This is based on this OAuth draft:
>
>
> https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/
>
>
>
>
> On Mon, May 25, 2026 at 7:22 AM Paola Di Maio <paola.dimaio@gmail..com>
> wrote:
>
>> Greetings everyone
>>
>> I am simply keeping an eye out on thiings and have come across this
>> https://github.com/workos/auth.md
>>
>> I wonder, how does this relate to everything else we are
>> discussing/doing/observing in this space?
>>
>> My understanding is that  this is an emerging protocol proposal that may
>> be relevant to ongoing discussions around federated identity, delegated
>> authorization, verifiable credentials, and autonomous software agents  but
>> not a W3C thing
>> Please feel free to share with related CGs
>>
>> brief analysis:
>>
>>  “auth.md”, an OAuth-based agent registration and authorization approach
>> intended for autonomous AI agents operating without traditional
>> browser-mediated consent flows.
>>
>> What makes this notable is not necessarily the specific proposal itself,
>> but the architectural gap it exposes:
>>
>> Current OAuth/OIDC assumptions are heavily browser- and human-centric:
>>
>>    -
>>
>>    redirect-based consent
>>    -
>>
>>    interactive authorization
>>    -
>>
>>    session-oriented mediation
>>    -
>>
>>    user-present trust boundaries
>>
>> Autonomous agents introduce different requirements:
>>
>>    -
>>
>>    long-lived delegated authority
>>    -
>>
>>    non-interactive authorization
>>    -
>>
>>    machine-verifiable delegation chains
>>    -
>>
>>    portable trust assertions
>>    -
>>
>>    agent-scoped identity distinct from user identity
>>    -
>>
>>    policy-constrained autonomous execution
>>
>> The proposal appears to combine:
>>
>>    -
>>
>>    OAuth Protected Resource Metadata
>>    -
>>
>>    signed identity assertions
>>    -
>>
>>    machine-readable discovery metadata
>>    -
>>
>>    delegated authorization semantics for agents
>>
>> This seems highly adjacent to:
>>
>>    -
>>
>>    FedID discussions around federated assertions and browser mediation
>>    -
>>
>>    VC/DID work on portable cryptographic identity
>>    -
>>
>>    emerging “agent identity” and “agent authorization” efforts across
>>    OpenID, DIF, and IETF communities
>>
>> One particularly interesting aspect is the use of discoverable metadata
>> (“auth.md”) as a capability advertisement layer for agent onboarding and
>> authorization.
>>
>> I suspect we are beginning to see a broader standards gap emerge between:
>>
>>    -
>>
>>    “users using software”
>>    and
>>    -
>>
>>    “software acting autonomously under delegated authority”
>>
>> Questions I think may be worth discussing:
>>
>>    -
>>
>>    Are OAuth/OIDC extensions sufficient for agent-native delegation?
>>    -
>>
>>    Should agent identity be modeled independently from user identity?
>>    -
>>
>>    What role should VC/DID infrastructure play in portable agent trust?
>>    -
>>
>>    How should revocation and policy constraints operate for long-lived
>>    autonomous agents?
>>    -
>>
>>    Do we need standardized discovery metadata for agent authorization
>>    capabilities?
>>
>> Relevant references:
>>
>>    -
>>
>>    https://workos.com/auth-md
>>    -
>>
>>    https://workos.com/blog/agent-registration-with-auth-md
>>    -
>>
>>    https://www.w3.org/groups/wg/fedid/
>>    -
>>
>>    https://www.w3.org/community/credentials/
>>
>> Curious whether others see this as:
>>
>>    -
>>
>>    an implementation detail,
>>    -
>>
>>    an OAuth extension opportunity,
>>    or
>>    -
>>
>>    the beginning of a broader agent identity/authz standardization
>>    problem.
>>
>>
>>