Use a Headless Domain With Verifiable Agent Credentials

When your agent presents a credential to a partner, give that partner one name to look up. Use it to connect the agent's public records with the identity claim the partner needs to verify.

Register a Headless Domain for your agent, publish its current discovery records, and bind that name to the issuer-signed credential your partner accepts. HeadlessDomains.com gives the agent a shareable name you can keep using as its service address or credential details change.

That gives partners a consistent place to begin. They can resolve the name, find the published verification references and use their own software to check the credential and live caller before granting access.

HeadlessDomains.com provides the name and discovery records. Credential issuance and checking run in your chosen software or your partner's system; HeadlessDomains.com does not provide a credential-checking tool for this workflow.

Give partners a name they can keep using

Suppose a partner integrates with your quote agent. Later, you move the quote API and replace an expiring credential. The partner needs current information without confusing the continuing agent with a different service.

With a maintained Headless Domain, you can update the published references while keeping the same name in your partner documentation and credential profile. Clients that resolve and refresh those records can find the new locations. Your partner still reviews changes that affect its trust decision, including new keys or a changed operator.

Give a new partner the name during onboarding. When its verifier needs current public information, it has a documented lookup path to follow. You can keep your existing runtime and credential provider, with their relevant references connected through the name’s records.

Find a Headless Domain for your agent, or use a name you already own. The walkthrough below shows the credential integration to build around it, using a fictional quote agent.

Choose the claim before choosing the software

The W3C Verifiable Credentials Data Model 2.0 separates the issuer that makes a claim, the holder that presents a credential and the verifier that checks it. Verification establishes the authenticity of the statement; the receiving party still decides whether to accept its issuer and claims.

For this pilot, your organization issues a credential to its agent. The partner runs the verifier inside its quote service. The agent requests a free test quote using synthetic inputs. It has no authority to approve an order or send money.

The intended claim is:

Our organization authorizes this agent to request test quotes under the headless name quote-desk.bpo, using the holder key bound to this credential.

quote-desk.bpo is fictional. The name and action vocabulary below illustrate an application design, not a registered service or standard credential type.

BlockChannel's identity essay inspired the original question behind this guide: how do people agree to recognize an identity? Here, settle that agreement during partner onboarding. The partner must accept your organization's issuer for this specific claim. Our identity coordination guide covers the wider adoption problem.

1. Write the credential profile both sides will implement

Write down the fields, meanings and verification rules your issuer and partner will support. That agreement is your credential profile. For the quote pilot, agree on these items:

The W3C data model does not supply your application's action vocabulary or guarantee that the holder is the credential subject. Your profile must establish the relationship this service requires. Keep issuer trust configuration under the receiver's control; a caller cannot nominate a new trusted issuer by adding one to its manifest.

2. Resolve the name and publish the discovery information

Use the public interfaces documented in the HeadlessDomains.com API reference:

GET https://headlessdomains.com/api/v1/resolve/YOUR-NAME
GET https://headlessdomains.com/api/v1/lookup/YOUR-NAME

Replace YOUR-NAME with the full registered name. Inspect the actual lifecycle response and returned resource links. The resolver documents separate responses for missing, expired, suspended and temporarily unavailable names. Pause this pilot when its required identity information cannot be established.

Resolution discovers records. It does not check a W3C credential, authenticate the caller or authorize the quote request.

The profile-management instructions explain how to host custom manifest and skill files and update the domain's agent-manifest and skill-md TXT pointers. Publish the service documentation and public verification references your integration needs. Use the authorized domain-management route, preserve unrelated records and read the result back.

Credential-specific metadata needs documented extension terms and a client that understands them. A new manifest field does not install verification software in another agent. Keep issued credentials private unless you deliberately intend their contents to be public.

Your service can keep its existing HTTPS address and runtime. Clients find it through the name's returned pointers. Keep the registration renewed and set a refresh policy so clients can discover changes. The post-registration guide covers general profile maintenance.

3. Establish name control and holder-key control separately

Before issuing the credential, decide what evidence establishes authority to manage the name. For this proposed pilot, use an issuer-created, short-lived challenge tied to the exact name, candidate holder key and issuance attempt.

Require evidence of an authorized domain-record change or an authenticated domain-management check that the issuer can validate. A challenge in an already linked file only demonstrates control of that file's hosting path. It is insufficient by itself to prove authority over the domain records.

If the integration uses a publication challenge, define the record and validation procedure explicitly, verify it through an independent lookup and account for caching. This challenge mechanism must be implemented by your integration; it is not a HeadlessDomains.com verification endpoint.

Separately, require the agent to sign a fresh issuance challenge with its candidate holder key. Verify that signature, reject reused or expired challenges, and issue only after the required name, operator and key evidence passes.

Name control does not prove a legal business identity or professional qualification. Those claims need their own evidence. Also document the lookup's trust boundary: trusting an HTTPS resolver response does not independently verify naming-network history, and a current manifest is not an immutable record of earlier ownership.

4. Issue with a supported securing mechanism

Choose a format your issuer and verifier both implement. W3C defines JOSE and COSE mechanisms and Data Integrity proofs. Select the library, supported algorithms and key-discovery rules together, then test that exact combination.

For the W3C VC 2.0 JOSE route, do not copy an older JWT example containing a vc or vp wrapper. The JOSE specification prohibits those JWT claim names. It also distinguishes signature expiry from the credential data's validFrom and validUntil; implement the applicable checks for each.

Use the chosen format's supported holder-binding mechanism. For example, the JOSE/COSE specification discusses confirmation-key information and recommends proof-of-possession binding. A public key merely listed beside a credential is not enough. The verifier must establish the protected binding and check the corresponding holder proof.

This guide uses VC Data Model 2.0 as its standards baseline. W3C also publishes VC Data Model 2.1 as a Working Draft; do not silently mix draft behavior into a 2.0 implementation.

The issuer and agent need separate keys. Protect each key where it is used, and document how to replace it.

5. Verify the caller before accepting its request

Use a presentation exchange supported by both applications. OpenID for Verifiable Presentations 1.0 is one standardized option. Its holder-binding checks include the intended verifier and a fresh nonce. Confirm that your implementation supports the selected credential format and deployment flow.

A custom pilot needs an explicitly designed exchange. For this example, bind the holder proof to a short-lived, single-use challenge, the receiving service and the intended quote request. Specify exactly how the request contents are represented and covered by the proof. A credential presentation alone does not automatically bind an arbitrary API request body.

The receiving service's verification code should reject the request unless all of these checks pass:

• The issuer is accepted for this claim, its signature verifies with an authenticated issuer key, and the credential matches the agreed profile.
• The credential is within its validity period and satisfies the required status checks.
• The subject, headless name, operator relationship and current approved holder binding match the service's expectations.
• The live holder proof verifies with the bound key and covers the correct recipient, challenge and request.
• The requested operation falls within the credential's claim and the receiver's local authorization policy.

Consume challenges atomically so concurrent copies cannot both pass. Keep replay state for the full acceptance window, including across restarts. Run these checks in verification and enforcement code; a language model reading the credential should not decide whether its signature is valid.

The quote API retains its normal authentication and access controls. If you later add operations that change state, implement their idempotency rules too. Rejecting reused proofs and preventing duplicate business operations are separate requirements.

6. Define how credentials stop working

W3C Bitstring Status List is a standardized option for publishing credential suspension or revocation status. Use it only with an implementation that supports its issuance and verification rules.

Set an explicit maximum age for status evidence and test what happens when fresh status cannot be fetched. For this pilot, reject the request when required evidence exceeds that limit. Caching affects how quickly a revocation reaches the next decision; a status mechanism does not promise instant rejection everywhere.

A public profile marked retired does not revoke a separately issued credential. The issuer must update the credential's supported status mechanism, and the receiving service must enforce the result.

Before a name transfer, revoke the affected old binding and remove the receiver's old approval. Require a new onboarding decision for the new operator. If the lookup cannot reliably establish whether ownership changed, add an authoritative check or a manual review. Do not infer ownership continuity from the name string alone.

7. Test the failures as well as the successful quote

Run an integration test with a fresh client that has the agreed issuer policy and protocol configuration. Give it the headless name rather than hard-coding the final service address. Confirm that it resolves the record, completes the presentation exchange and gets the expected synthetic quote.

Then test a copied credential with the wrong key, an unknown issuer, a replayed challenge, the wrong recipient, altered request contents, an expired credential and a revoked credential. Every case should be rejected for the expected reason. Test concurrent replays and a verifier restart as well.

Cut off status retrieval. Rotate the holder key, then change the named operator in separate tests. Check that each result matches the agreed recovery or refusal rules. Save the test results and configuration versions without logging private keys or unnecessary credential contents.

This is the credential-specific implementation beneath the broader Agent Identity Stack. Passing it supports one defined access decision. It does not establish the agent's work quality or grant wider permissions.

Give your developer a bounded brief

Prepare a verifiable-credential pilot for my headless domain [NAME]
and partner quote service [SERVICE]. Use approved issuer [ISSUER].

Implement issuance and verification in our chosen software.
Use HeadlessDomains.com only for the name and discovery records.
Do not assume it provides a credential checker.

Agree on the credential profile, establish name and holder-key control,
and bind a fresh presentation to one synthetic quote request.
Implement receiver authorization, replay protection and status checks.
Test invalid proofs, revocation, key rotation and operator changes.

Preserve existing records. Prepare exact changes for review.
Keep private keys and credentials out of public files.
Report what is designed, implemented, tested and still unverified.

Put your agent's name in the next partner introduction

Choose the agent you want customers or partners to recognize. Register its Headless Domain, connect the public records to your existing service, and include the name in the credential profile you agree with your first partner.

You can establish that public starting point while your developer builds the credential integration. Describe what is available today, then add the verification references when the supporting software is ready.

Already have a name? Use the HeadlessDomains.com machine instructions to prepare its records for this workflow.

Give your agent a name partners can return to.Search HeadlessDomains.com and register the name for your agent.