Product Passport × AT Protocol

Link a Product Passport to a Bluesky post.

Verifable's connected-client foundation can publish a standard Bluesky post that links to a public Product Passport. The post remains a public statement; the passport remains the accountable record. The controlled publishing flow works in integration tests; it is not yet available from the production Wallet.

Working foundation. Visible boundary.

01 · Source

Public Product Passport

The resolvable record remains the source for product facts and provenance.

Accountable record

02 · Gate

Disclosure review

The public URL and post are reviewed. Cancelling this step publishes nothing.

Explicit human action

03 · Reach

Standard Bluesky post

A normal app.bsky.feed.post carries the passport URL as an external link.

Public conversation

Implemented

Connect an account, review disclosure, publish a public passport link and record what happened.

Shared foundation

DIDs and signatures across Product Passports, Verifiable and Lumoin's AT Protocol work.

Not claimed

No VC embedded in the post, custom DPP Lexicon, verified organisation mandate or public Wallet-DID ↔ AT-DID binding.

This flow is integration-tested, but it is not a production publishing service yet.

How does Verifable connect wallets and AT Protocol accounts?

The development foundation runs AT Protocol OAuth through a backend-for-frontend. The person approves the requested permissions at their own Personal Data Server (PDS); the browser does not receive the OAuth token or DPoP key.

The AT DID is the durable account identifier; the handle and PDS location may change. The connected-account view shows the handle, AT DID, PDS and permission. Disconnecting ends the test connection without touching passport or credential data.

Wallet side Person · organisation · credentials Who may act, once verified

AT Protocol side AT DID · PDS · OAuth grant What this connection permits

These are two authority domains, not one substituted identity. A public Wallet-DID ↔ AT-DID credential or binding is not claimed today.

Can Verifable be used as a Bluesky client?

In the implemented development foundation: reading feeds, posts, and threads; composing ordinary posts and replies; and publishing links to public Digital Product Passport pages. Every post Verifable writes is a standard app.bsky.feed.post record, readable in a standard Bluesky client.

This is not a production service or full client parity. There are no direct messages. Moderation state — blocks, mutes, labels — set at the AT Protocol or Bluesky level is always respected as it arrives and is never bypassed because a post happens to be relevant to a Digital Product Passport.

How are DPP facts separated from social statements?

Every social statement the current foundation records carries an epistemic classification — question, observation, opinion, proposal, request, offer, commitment, verified-claim, credential-reference, inference, or system-status — and a provenance label such as authored or agent-suggested.

A statement never becomes authoritative passport evidence by virtue of being posted, linked, or widely repeated. The current AT Protocol feature keeps a separate classified statement log. Veritas does not yet ingest these statements into the evidence graph.

Can an SME publish through a verified organisational role?

Not yet. The data model has an organisational publication-context shape, but the current composer offers personal publication only. A role label becomes meaningful only when a real Wallet authority read supplies the organisation, mandate and applicable policy; an internal context label is not a portable mandate.

What may an agent do?

Today an agent can prepare a draft from a public passport URL, but it cannot publish. A person must review the disclosure and use the normal publish action. This is not a portable agent mandate or autonomous publishing authority.

How is restricted DPP information protected?

The implemented bridge sends a standard post and the public passport URL—not a credential or restricted graph. A passport-linked publish request is refused until the person confirms the disclosure step; cancelling publishes nothing. A fuller production preview must still show the exact account, URL, included text and excluded fields before release.

Permissioned, access-controlled data on AT Protocol itself is still an active area of protocol development. Verifable does not put restricted records on public AT Protocol repositories, now or as a matter of design — restricted data simply does not travel that path.

Where does Veritas enter?

Next, not as a current public service. The intended ingestion is narrow: explicit public passport links, Verifable-authored posts and configured accounts. Veritas can then preserve source distinctions and make public statements queryable without turning them into product evidence. General social-graph crawling and inference from follows or likes are outside this design.