DirectRFQ A2A Business Card Specification. Canonical specification for structured, verifiable and agent-ready business identity
Status: DirectRFQ public specification, version 0.1. Publication date: 20 July 2026. This document is the canonical textual definition of the DirectRFQ A2A Business Card v0.1. It defines an independent business-data framework. It is not an official component of the Agent2Agent Protocol and it does not redefine the technical A2A Agent Card.
Abstract
The DirectRFQ A2A Business Card is a structured representation of a business designed for human buyers, search engines, answer engines, procurement systems and AI agents.
It enables a system to identify the correct legal entity, understand the commercial roles it performs, evaluate relevant products and capabilities, inspect evidence, determine whether the business may fit a purchasing requirement and select an appropriate route for a Direct RFQ or another authorised action.
This specification defines:
the minimum information required for a conforming A2A Business Card;
a common vocabulary for business identity, commercial roles, markets, capabilities, evidence and qualification;
lifecycle, freshness, correction and governance requirements;
Direct RFQ routes and agent-actionable interfaces;
progressive readiness levels from Business Listed to Agent Transactable;
publication, discovery, validation, privacy and security rules;
links to technical A2A Agent Cards, WebMCP, MCP, OpenAPI and Agentic Resource Discovery where those implementations actually exist.
An A2A Business Card does not itself approve a supplier, verify every claim, guarantee availability, create a binding quotation, authorise an AI agent or complete a transaction.
1. Status of this specification
1.1 Specification identity
| Property | Value |
| Specification name | DirectRFQ A2A Business Card Specification |
| Specification version | 0.1 |
| Status | Public specification; initial implementation version |
| Publication date | 20 July 2026 |
| Specification owner | DirectRFQ.com |
| Primary language | English |
| Canonical page | Recommended: https://directrfq.com/specifications/a2a-business-card/v0.1/ |
| JSON Schema location | Recommended: https://directrfq.com/schemas/a2a-business-card/0.1/schema.json |
| Change policy | Versioned; later versions must not silently alter v0.1 semantics |
The canonical page for version 0.1 SHOULD remain available after newer versions are published. Corrections that do not change meaning MAY be applied to the page, but semantic changes MUST result in a new specification version.
1.2 Independent relationship to the Agent2Agent Protocol
The Agent2Agent Protocol defines a technical Agent Card published by an operational A2A server. The Agent Card describes an agent, its supported interfaces, capabilities, skills and security requirements.
The DirectRFQ A2A Business Card describes a business organisation, its commercial identity, roles, capabilities, qualification conditions, evidence and enquiry routes.
| DirectRFQ A2A Business Card | Technical A2A Agent Card |
| Describes a business organisation | Describes an operational AI agent or agentic service |
| Supports entity resolution and supplier qualification | Supports agent discovery and protocol interaction |
| May exist without an AI agent | Requires an A2A implementation |
| Links to products, capabilities, evidence and RFQ routes | Lists agent interfaces, capabilities, skills and security |
| Uses the DirectRFQ specification | Uses the Agent2Agent Protocol specification |
A conforming Business Card MUST NOT present itself as an official A2A Protocol Agent Card.
A Business Card MAY link to an A2A Agent Card only when the referenced service is operational and the linked document conforms to the applicable A2A Protocol version.
1.3 Intended audience
This specification is intended for:
B2B suppliers and service providers;
manufacturers, distributors, integrators and contractors;
procurement and supplier-management platforms;
industry directories and marketplaces;
search, answer and recommendation systems;
developers of AI agents and agentic commerce systems;
providers of verification, identity and compliance services;
publishers of A2A Product Cards, Capability Cards and Direct RFQ Cards.
2. Design objectives
The specification has seven primary objectives.
2.1 Resolve the business entity
The card should help distinguish:
a legal entity from a brand;
a parent company from a subsidiary or branch;
a manufacturer from a distributor or integrator;
a supplier from an intermediary;
an official domain from an unrelated or similarly named website;
the entity described by the card from the entity that will issue a quotation or contract.
2.2 Describe commercial roles without unsupported assumptions
A company may manufacture one category, distribute another, integrate third-party systems, rent selected equipment and service products supplied by several brands.
The card MUST associate each declared commercial role with its applicable scope. A generic claim such as “manufacturer and distributor” is insufficient when it causes a buyer or agent to assume that the company manufactures every item shown on its website.
2.3 Make capabilities qualifiable
The card should provide enough structured context to determine whether a business may fit a defined need. It should expose important conditions, exclusions, territories, qualification inputs and human-review triggers instead of presenting only marketing descriptions.
2.4 Connect material claims with evidence
The specification separates:
a statement published by the subject business;
a source supporting the statement;
a check performed by the publisher or another party;
independent verification;
transaction-observed evidence;
the validity period of time-sensitive information.
2.5 Enable a structured Direct RFQ
Where appropriate, the card should identify:
the commercial intent supported by an enquiry route;
the categories or capabilities to which the route applies;
required and optional inputs;
accepted files;
validation conditions;
authentication requirements;
expected response;
circumstances requiring a human specialist.
2.6 Support gradual implementation
A small industrial supplier should be able to begin with a canonical public record and later add verification, structured qualification, Direct RFQ forms, APIs, WebMCP tools or an operational A2A agent.
The framework MUST NOT imply that every company requires autonomous transactions.
2.7 Preserve human accountability
The card should make automation more precise without obscuring responsibility. It MUST distinguish the subject business, data owner, publisher, verification provider, RFQ operator and contracting entity where those roles differ.
3. Non-goals
This specification does not:
create a public company register;
replace official corporate, tax or beneficial-ownership registers;
perform legal, financial, sanctions, cybersecurity or compliance due diligence;
approve or certify a supplier;
guarantee that a product, service or production slot is available;
define a Digital Product Passport;
replace a supplier onboarding questionnaire;
define an agent communication protocol;
grant an agent authority to negotiate, order, pay or enter into a contract;
make published prices or terms binding unless an authorised offer expressly states that they are binding;
guarantee visibility, citation, ranking or recommendation in any external AI or search system.
4. Normative language
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY and OPTIONAL are to be interpreted as described in BCP 14, RFC 2119 and RFC 8174 when, and only when, they appear in uppercase.
Informative examples explain the specification but do not override normative requirements.
5. Core terminology
| Term | Definition |
| A2A Business Card | A canonical, structured business record conforming to this specification |
| Card | An A2A Business Card document or its equivalent human-readable representation |
| Subject business | The legal entity or formally identified organisational unit described by the card |
| Data owner | The organisation accountable for the accuracy and maintenance of the business data |
| Publisher | The entity that prepares or hosts the card |
| Verification provider | The entity that checks selected claims or evidence |
| RFQ operator | The entity that receives, validates, routes or processes enquiries |
| Contracting entity | The legal entity expected to issue a formal quotation, order confirmation or contract |
| Claim | A statement about the subject business, its roles, capabilities or commercial conditions |
| Evidence | A source, document, record or observation associated with a claim |
| Qualification rule | A condition used to assess fit, request missing information or trigger human review |
| Direct RFQ route | A declared path for submitting a structured commercial enquiry |
| Interface | A human-facing or machine-facing mechanism through which data or actions are exposed |
| Public layer | Information that may be accessed without buyer verification |
| Restricted layer | Information available only after identity, purpose, role or entitlement checks |
| Transactional layer | Information or actions available only within an authorised commercial workflow |
| Agent Qualifiable | Sufficiently structured for an agent to assess potential fit without claiming final supplier approval |
| A2A Enabled | Linked to an operational agent with a valid technical A2A Agent Card and compatible interface |
| Agent Transactable | Able to support defined commercial actions under a documented mandate, approval and audit framework |
6. Conformance model
6.1 Conforming card
A document conforms to A2A Business Card v0.1 Core when it:
declares specification version 0.1;
uses a stable card identifier and canonical URL;
identifies the subject business;
includes at least one identifier suitable for entity resolution;
declares at least one commercial role;
describes at least one offering category or capability;
identifies at least one contact point or enquiry route;
provides lifecycle and governance information;
distinguishes claims from verification;
satisfies the minimum field requirements in this document;
does not make a false A2A Agent Card or transaction-authority claim.
6.2 Conforming publisher
A publisher conforms when it:
publishes a conforming card;
identifies the data owner and correction route;
applies the declared validation and update policy;
preserves version history or change records;
removes, expires or marks information that it knows is materially outdated;
does not describe an unperformed check as verification.
6.3 Conforming consumer
A consuming system conforms when it:
validates required fields before relying on the card;
treats unknown extensions safely;
does not infer final supplier approval from card publication;
respects access levels and security requirements;
evaluates freshness and evidence scope;
does not treat a self-declared claim as independently verified;
requires separate authorisation for commercial actions.
6.4 Conformance profiles
| Profile | Additional requirements |
| Core | Minimum identity, role, offering, contact, lifecycle and governance fields |
| Discoverable | Canonical HTML page, machine-readable representation and declared discovery link |
| Evidence-Linked | Material claims reference evidence and verification status |
| Agent-Qualifiable | Structured fit criteria, exclusions, required inputs and human-review triggers |
| Direct-RFQ-Ready | At least one structured RFQ route with inputs, validation and response semantics |
| Agent-Actionable | At least one callable, schema-described action with authentication and confirmation rules |
| A2A-Enabled | Valid link to an operational technical A2A Agent Card |
| Agent-Transactable | Documented mandate, approval, audit, identity and transaction controls |
A card MAY declare more than one profile. A higher profile does not automatically imply every lower profile unless all lower-profile requirements are actually satisfied.
7. Publication and discovery
7.1 Canonical human-readable page
Every public card MUST have one canonical HTTPS page intended for human review.
The page SHOULD:
identify the subject business near the beginning;
disclose the card version, status and last update date;
present important limitations and verification status visibly;
expose a correction contact;
link to the machine-readable representation;
link to referenced Product Cards, Capability Cards, evidence and Direct RFQ routes;
be accessible without client-side execution for core identity data where practical.
7.2 Machine-readable representation
A Discoverable card MUST provide a JSON representation using UTF-8 and the media type “application/json”.
The RECOMMENDED stable domain-local path is:
The canonical HTML page SHOULD declare the representation using an alternate link:
link rel=”alternate” type=”application/json” href=”https://example.com/a2a-business-card.json”
The JSON document SHOULD link back to the canonical human-readable page.
7.3 JSON-LD
A publisher MAY additionally expose JSON-LD. Where Schema.org terms are applicable, the publisher SHOULD map the subject business to Schema.org Organization or a more specific subtype.
JSON-LD is an interoperability representation. It does not replace the DirectRFQ fields required for qualification, evidence, governance and RFQ routing.
7.4 HTTP behaviour
A machine-readable card SHOULD support:
HTTPS;
a stable URL;
an appropriate Content-Type header;
ETag and Last-Modified validators;
cache-control consistent with the volatility of the data;
redirects that preserve the canonical identity;
a 410 Gone response or explicit archived status when a card is permanently withdrawn.
Consumers SHOULD follow redirects cautiously and SHOULD revalidate ownership when the registrable domain changes.
7.5 Agentic Resource Discovery
A publisher MAY reference the Business Card from an “ai-catalog.json” catalogue or another Agentic Resource Discovery implementation.
The Business Card should be treated as business-identity and qualification metadata. It MUST NOT be advertised as an executable A2A agent, MCP server or OpenAPI service unless the corresponding resource exists.
7.6 Technical agent discovery
If the subject business operates or formally appoints an A2A-compatible agent, the Business Card MAY link to the technical Agent Card, normally discovered through the mechanism defined by the applicable A2A Protocol version.
The existence of a link does not by itself prove that the agent has authority to bind the subject business.
8. Root data model
8.1 Root object
The machine-readable card is a JSON object. Property names in the DirectRFQ v0.1 model use lower camel case.
| Field | Requirement | Type | Purpose |
| type | MUST | string | Fixed value: A2ABusinessCard |
| specificationVersion | MUST | string | Fixed value for this specification: 0.1 |
| cardId | MUST | absolute URI | Stable identifier for the card |
| cardVersion | MUST | string | Version of the individual card |
| status | MUST | controlled string | draft, active, outdated, suspended or archived |
| canonicalUrl | MUST | HTTPS URL | Canonical human-readable page |
| machineReadableUrl | SHOULD | HTTPS URL | Canonical JSON representation |
| issuedAt | MUST | date-time | First publication time for this card series |
| updatedAt | MUST | date-time | Last material update |
| validThrough | MAY | date-time | Overall validity limit |
| nextReviewAt | SHOULD | date-time | Planned review time |
| language | MUST | BCP 47 tag | Primary language |
| availableLanguages | MAY | array | Other published language variants |
| profiles | MUST | array | Claimed conformance profiles |
| subject | MUST | object | Subject business identity |
| brands | MAY | array | Brands linked to the subject business |
| relationships | MAY | array | Parent, branch, partner or other entity relationships |
| commercialRoles | MUST | non-empty array | Roles performed by the business |
| markets | MUST | object | Territories, industries and buyer types |
| offerSummary | CONDITIONAL | array | Products, services or categories |
| capabilities | CONDITIONAL | array | Business capabilities |
| qualification | SHOULD | object | Fit rules, required information and review triggers |
| claims | SHOULD | array | Explicit business claims |
| evidence | SHOULD | array | Evidence records referenced by claims |
| contactPoints | CONDITIONAL | array | Human or organisational contact routes |
| rfqRoutes | CONDITIONAL | array | Structured enquiry routes |
| interfaces | MAY | array | HTML, form, API, WebMCP, MCP or A2A links |
| governance | MUST | object | Ownership, publishing, verification and correction roles |
| accessPolicy | SHOULD | object | Public and restricted information layers |
| signatures | MAY | array | Integrity and authenticity signatures |
| extensions | MAY | object | Namespaced extension data |
At least one of “offerSummary” or “capabilities” MUST be present.
At least one of “contactPoints” or “rfqRoutes” MUST be present.
8.2 Stable identity
The “cardId” MUST be an absolute URI and SHOULD remain stable across card updates.
The “cardVersion” changes when the individual card changes. The “specificationVersion” identifies the data model and MUST NOT be changed merely because the company data changed.
The canonical URL MAY change after a domain migration, but the publisher SHOULD preserve redirects and SHOULD keep the stable “cardId” where control and identity continuity can be demonstrated.
9. Subject business
9.1 Subject object
| Field | Requirement | Description |
| legalName | MUST | Official registered name |
| entityType | MUST | Legal entity, sole trader, public body, branch or other defined type |
| registeredCountry | MUST | ISO 3166-1 alpha-2 country code |
| registeredAddress | SHOULD | Official address suitable for public disclosure |
| operationalLocations | MAY | References to separate location objects |
| identifiers | MUST | One or more organisation identifiers |
| website | MUST | Official canonical website |
| foundingDate | MAY | Date or year, with source |
| status | SHOULD | active, inactive, restructuring, dissolved or unknown |
| parentOrganisation | MAY | Reference to parent entity |
| contractingEntities | SHOULD | Entities that may issue quotations or contracts |
| sameAs | MAY | Authoritative identity links |
9.2 Organisation identifiers
An identifier object SHOULD contain:
| Field | Requirement | Description |
| scheme | MUST | Identifier scheme |
| value | MUST | Identifier value |
| country | MAY | Issuing country |
| issuer | MAY | Issuing authority or registry |
| uri | MAY | Resolvable registry or identity URL |
| status | MAY | active, inactive, unconfirmed or unknown |
| checkedAt | MAY | Date on which the identifier was checked |
| evidenceRefs | MAY | Supporting evidence references |
Supported schemes MAY include:
national company registration number;
tax identifier;
VAT identifier;
LEI;
D-U-N-S;
GLN;
ISO 6523 identifier;
trade licence identifier;
other jurisdiction-specific identifiers.
Publishers MUST NOT include sensitive personal identifiers merely to strengthen an organisation record.
Where multiple legal entities use one brand or website, the card MUST make the relationship and contracting scope explicit.
10. Brands and organisational relationships
10.1 Brand object
A brand object SHOULD contain:
brand name;
brand identifier;
owner or authorised user;
relationship to the subject business;
applicable countries or categories;
official URL;
trademark or registry reference where appropriate;
evidence and validity dates.
The presence of a brand on a website MUST NOT be interpreted as proof of ownership, authorised distribution or service rights.
10.2 Relationship object
Relationship types MAY include:
parentOrganisation;
subsidiary;
branch;
department;
tradingName;
brandOwner;
authorisedDistributor;
implementationPartner;
servicePartner;
subcontractor;
marketplaceOperator;
contractingEntity;
RFQOperator.
Every material relationship SHOULD declare its scope, evidence and validity.
11. Commercial roles
11.1 Role object
Each commercial role MUST be scoped.
| Field | Requirement | Description |
| roleId | MUST | Stable local identifier |
| role | MUST | Controlled role value |
| appliesTo | MUST | Products, services, capabilities, brands or categories |
| territories | SHOULD | Countries or regions where the role applies |
| performedBy | SHOULD | Subject, branch, partner or subcontractor |
| conditions | MAY | Material limitations |
| evidenceRefs | SHOULD | Evidence supporting the role |
| validThrough | MAY | End of validity |
11.2 Recommended role vocabulary
manufacturer;
contractManufacturer;
distributor;
authorisedDistributor;
reseller;
importer;
exporter;
systemsIntegrator;
engineeringProvider;
serviceProvider;
maintenanceProvider;
rentalProvider;
logisticsProvider;
testingProvider;
certificationProvider;
contractor;
broker;
marketplaceOperator;
consultancy;
other.
An “other” value SHOULD include a human-readable definition.
12. Markets and coverage
The “markets” object SHOULD describe:
countries and regions served;
delivery, installation and service territories;
industries served;
customer types;
languages supported;
minimum or maximum project scale where material;
excluded territories, industries or applications;
regulatory or certification constraints;
cross-border limitations.
Country values SHOULD use ISO 3166 codes. Language values SHOULD use BCP 47 tags. Industry classifications SHOULD identify the classification system used.
A card MUST distinguish “can sell to”, “can deliver to”, “can install in” and “can service in” when those territories differ.
13. Offer summary and linked cards
13.1 Offer summary object
The Business Card provides a business-level summary. Detailed product and capability data SHOULD be placed in linked A2A Product Cards or A2A Capability Cards.
| Field | Requirement | Description |
| offeringId | MUST | Stable identifier |
| type | MUST | product, service, capability or category |
| name | MUST | Human-readable name |
| category | MUST | Category and classification system where available |
| description | SHOULD | Concise scope description |
| commercialRoleRefs | MUST | Applicable role references |
| territories | SHOULD | Applicable markets |
| url | SHOULD | Human-readable detail page |
| cardUrl | MAY | Product or Capability Card URL |
| availabilityStatus | MAY | Current status with update date |
| evidenceRefs | MAY | Supporting evidence |
Time-sensitive price, stock, lead-time or capacity data SHOULD normally be held in an offer, Product Card, Capability Card or RFQ response rather than copied into the Business Card.
If time-sensitive data is included, it MUST state:
currency and unit;
applicable configuration and quantity;
tax basis;
validity period;
update time;
material conditions;
whether the value is indicative or binding.
14. Capability model
14.1 Capability object
A capability describes what the business can perform, produce, configure, test, install, maintain or deliver.
| Field | Requirement | Description |
| capabilityId | MUST | Stable identifier |
| name | MUST | Capability name |
| description | MUST | Operational description |
| category | SHOULD | Controlled classification |
| performedBy | MUST | Entity, location, team or partner |
| locations | SHOULD | Applicable facilities |
| inputs | MAY | Required materials, data or conditions |
| outputs | MAY | Produced result or deliverable |
| capacity | MAY | Structured capacity with unit and period |
| constraints | SHOULD | Technical, geographic or commercial limitations |
| certifications | MAY | Relevant certifications |
| evidenceRefs | SHOULD | Evidence supporting material claims |
| updatedAt | MUST | Last update |
| validThrough | MAY | Validity limit |
| capabilityCardUrl | MAY | Detailed A2A Capability Card |
14.2 Capacity claims
Capacity values MUST include a unit, period and scope.
A statement such as “high production capacity” is not a structured capacity claim.
If available capacity changes frequently, the card SHOULD describe the general capability and provide a separate authenticated or time-bound route for current capacity.
15. Qualification model
15.1 Purpose
Qualification does not mean final supplier approval. It determines whether the business may be a plausible match and what information is required next.
15.2 Qualification object
The qualification object SHOULD contain:
suitable buyer types;
supported territories;
supported applications;
minimum and maximum project conditions;
technical prerequisites;
required buyer inputs;
exclusions;
information-gap rules;
human-review triggers;
onboarding prerequisites;
regulated-use restrictions.
15.3 Qualification rule
| Field | Requirement | Description |
| ruleId | MUST | Stable identifier |
| appliesTo | MUST | Offering, capability, market or RFQ route |
| criterion | MUST | Field or business condition evaluated |
| operator | SHOULD | equals, includes, greaterThan, lessThan, inRange, present or custom |
| expectedValue | MAY | Comparison value |
| unit | MAY | Measurement unit |
| outcome | MUST | potentialFit, notFit, informationRequired or humanReview |
| reason | SHOULD | Human-readable reason |
| evidenceRefs | MAY | Evidence supporting the rule |
Automated qualification rules MUST be treated as decision support unless the publisher explicitly documents a different authorised process.
Rules involving safety, regulated applications, sanctions, credit, contractual authority or unusual technical risk SHOULD trigger human review.
16. Claims, evidence and verification
16.1 Claim object
Material statements SHOULD be represented as explicit claims.
| Field | Requirement | Description |
| claimId | MUST | Stable identifier |
| subjectRef | MUST | Entity, role, capability or offering described |
| predicate | MUST | Property or relationship asserted |
| value | MUST | Asserted value |
| statement | SHOULD | Human-readable form |
| assertedBy | MUST | Party making the claim |
| evidenceRefs | SHOULD | Supporting evidence |
| verificationStatus | MUST | Controlled status |
| verifiedBy | MAY | Party that performed a check |
| verifiedAt | MAY | Verification time |
| validThrough | MAY | Claim validity limit |
| status | MUST | active, disputed, expired, withdrawn or unknown |
16.2 Evidence object
| Field | Requirement | Description |
| evidenceId | MUST | Stable identifier |
| type | MUST | register, certificate, document, webpage, audit, transactionRecord or other |
| title | MUST | Human-readable title |
| issuer | SHOULD | Source or issuing entity |
| url | MAY | Source URL |
| documentHash | MAY | Integrity hash |
| issuedAt | MAY | Issue date |
| checkedAt | SHOULD | Date checked by publisher or verifier |
| validThrough | MAY | Evidence validity limit |
| accessLevel | MUST | public, verifiedBuyer, confidential or transactional |
| description | SHOULD | Scope and limitations |
16.3 Verification status vocabulary
| Status | Meaning |
| unverified | No check is represented |
| selfDeclared | Published by or on behalf of the subject business |
| sourceMatched | Matched to a declared external source |
| documentChecked | A named document was inspected for the stated scope |
| independentlyVerified | Checked by an identified independent party |
| transactionObserved | Supported by a relevant observed transaction or operational record |
| disputed | A material challenge is unresolved |
| expired | The verification or evidence is no longer current |
Verification MUST be scoped. Checking a company registration number does not verify its manufacturing capability, authorisation, stock, financial condition or product compliance.
16.4 Evidence access
Restricted evidence MAY be referenced without publishing the underlying document.
A public record MAY state:
that evidence exists;
its type and issuer;
the claim it supports;
the verification status;
the conditions under which an authorised buyer may request access.
It MUST NOT expose confidential documents, personal data, credentials or trade secrets merely to improve machine readability.
16.5 Signatures and integrity
A card MAY carry one or more digital signatures.
Where a JSON representation is signed, the publisher SHOULD use a documented canonicalisation and signature method. JSON Canonicalization Scheme under RFC 8785 and JSON Web Signature under RFC 7515 are suitable reference mechanisms.
A signature can support integrity and publisher authenticity. It does not prove that every statement in the signed document is true.
17. Contact points
17.1 Contact object
| Field | Requirement | Description |
| contactId | MUST | Stable identifier |
| purpose | MUST | sales, RFQ, technical, service, compliance, correction or other |
| department | SHOULD | Responsible organisational unit |
| channels | MUST | One or more contact channels |
| languages | SHOULD | Supported languages |
| territories | MAY | Applicable countries or regions |
| businessHours | MAY | Availability window and time zone |
| responseTarget | MAY | Non-binding response objective |
| accessLevel | MUST | public, verifiedBuyer or transactional |
| status | MUST | active or inactive |
Publishers SHOULD prefer role-based addresses over personal contact details for durable public cards.
Response targets MUST identify whether they are objectives, service commitments or contractual service levels.
18. Direct RFQ routes
18.1 RFQ route object
| Field | Requirement | Description |
| routeId | MUST | Stable identifier |
| name | MUST | Route name |
| intent | MUST | productQuote, solutionSelection, service, rental, spareParts, capacity, compliance or other |
| appliesTo | MUST | Offering, capability or category references |
| channelType | MUST | webForm, email, api, webmcp, mcp, a2a or other |
| endpoint | MUST | URL or declared channel |
| method | MAY | HTTP or protocol method |
| requiredInputs | MUST | Structured list of required information |
| optionalInputs | MAY | Structured list of optional information |
| acceptedFiles | MAY | File types and limits |
| validationRules | SHOULD | Input validation conditions |
| authentication | MUST | none or declared authentication scheme |
| humanReview | MUST | Conditions and responsible role |
| expectedResult | MUST | Acknowledgement, qualification response, quotation or other outcome |
| responseTarget | SHOULD | Expected timing and status |
| termsUrl | SHOULD | Applicable terms or enquiry conditions |
| privacyUrl | MUST | Privacy information |
| status | MUST | active, paused or retired |
18.2 Required input definition
An input definition SHOULD contain:
field identifier;
label;
description;
data type;
unit where applicable;
required status;
allowed values or range;
confidentiality class;
validation message;
example.
18.3 Commercial semantics
Submission of a Direct RFQ normally represents a request for information or quotation, not an order.
The route MUST state the expected legal and commercial effect of submission.
An automated acknowledgement MUST NOT be presented as an accepted order, binding price or confirmed delivery date unless an authorised workflow expressly supports that outcome.
18.4 Human escalation
Human review SHOULD be required when:
the request falls outside declared ranges;
essential information is missing or contradictory;
safety or regulated use is involved;
a non-standard configuration is requested;
contractual exceptions are proposed;
the estimated value exceeds a mandate threshold;
sanctions, identity, credit or security checks are required;
a buyer requests confidentiality or custom terms;
the automated result has material uncertainty.
19. Interfaces and agentic actions
19.1 Interface object
| Field | Requirement | Description |
| interfaceId | MUST | Stable identifier |
| type | MUST | html, json, jsonld, directRfqForm, openapi, webmcp, mcp, a2aAgentCard or aiCatalog |
| url | MUST | Interface or discovery URL |
| protocol | MAY | Protocol name |
| version | MAY | Interface or protocol version |
| capabilities | MAY | Declared functions |
| authentication | MUST | Access requirement |
| documentationUrl | SHOULD | Human-readable documentation |
| status | MUST | experimental, active, deprecated or retired |
| lastCheckedAt | SHOULD | Operational check time |
19.2 WebMCP
A company MAY expose Direct RFQ forms or other website functions as WebMCP tools.
A WebMCP interface MUST separately define:
tool name and purpose;
input schema;
validation;
expected result;
confirmation behaviour;
authentication and access;
privacy and data handling;
human escalation.
The Business Card should link to the interface; it should not duplicate the complete WebMCP implementation.
19.3 OpenAPI and MCP
An API interface SHOULD link to an OpenAPI description where applicable.
An MCP interface MUST refer to an operational MCP server and MUST declare its security and access requirements.
MCP is a tool and context protocol. It MUST NOT be represented as proof that another independent agent can interact through the Agent2Agent Protocol.
19.4 A2A Agent Card
An “a2aAgentCard” interface MUST point to a valid technical Agent Card.
The Business Card SHOULD additionally state:
who operates the agent;
whether the agent is operated by the subject business or an appointed provider;
the business functions for which the agent may act;
whether the agent can only provide information, prepare an RFQ, negotiate within limits or perform another action;
the source of its authority;
human confirmation and audit requirements.
20. Governance
20.1 Required governance roles
The governance object MUST identify:
subject business;
data owner;
publisher;
correction contact;
specification version;
applicable jurisdiction.
It SHOULD identify, where applicable:
verification provider;
RFQ operator;
contracting entity;
technical interface operator;
security contact;
privacy contact.
20.2 Role separation
The same organisation may perform several roles, but a consumer MUST NOT silently assume that the roles are identical.
For example:
a marketplace may publish the card while the supplier owns the data;
a verification provider may check selected claims;
a service company may operate the RFQ route;
a regional subsidiary may issue the quotation;
a technology provider may operate the agent.
20.3 Correction process
A conforming card MUST provide a correction route.
The correction policy SHOULD describe:
who may report an error;
how identity is verified;
expected acknowledgement time;
how disputed claims are marked;
how urgent security or impersonation reports are handled;
how corrections affect version history.
21. Lifecycle and freshness
21.1 Card status
| Status | Meaning |
| draft | Not intended for production reliance |
| active | Current according to the declared update policy |
| outdated | Known to require material review |
| suspended | Temporarily unavailable for reliance or action |
| archived | Historical record; not current |
21.2 Time fields
All date-time values SHOULD use RFC 3339 format with an explicit time-zone offset or “Z”.
Each time-sensitive claim SHOULD have its own update or validity information. The overall “updatedAt” value does not make every nested claim current.
21.3 Review frequency
Publishers SHOULD assign review frequencies according to volatility.
| Information | Typical review approach |
| Legal identity | Event-driven and periodic register check |
| Contact points | Quarterly or on change |
| Commercial roles | On authorisation change and at least annually |
| Territories and service coverage | Quarterly or on change |
| Capabilities | On operational change and at least annually |
| Certificates | Before expiry and on replacement |
| Stock, prices and lead times | Separate time-bound data source |
| RFQ routes and interfaces | Automated monitoring plus periodic human check |
These intervals are guidance, not universal requirements.
21.4 Versioning
The card SHOULD use a three-part version such as 1.2.3:
major for a change that may alter identity, scope or interpretation;
minor for a material backward-compatible addition;
patch for a correction that does not change intended semantics.
Publishers SHOULD maintain a change log containing date, version, change summary and responsible publisher.
22. Access layers and privacy
22.1 Information layers
The framework recognises four access levels:
| Layer | Description |
| public | Available without buyer verification |
| verifiedBuyer | Available after identity or purpose checks |
| confidential | Shared under defined confidentiality controls |
| transactional | Available only within an authorised transaction workflow |
The public card MAY reference the existence of restricted information without disclosing it.
22.2 Data minimisation
A publisher MUST collect and publish only information necessary for the declared purposes.
The card SHOULD avoid:
personal mobile numbers where a role address is sufficient;
personal identifiers;
bank details;
credentials, tokens or API keys;
customer-confidential information;
trade secrets;
security architecture details that create unnecessary risk;
unrestricted access to compliance or technical documents that contain sensitive information.
22.3 Buyer-submitted data
An RFQ route MUST state how submitted data is used, retained, secured and shared.
Buyer files MUST be treated as untrusted input and SHOULD be scanned, size-limited and isolated before processing.
23. Security considerations
23.1 The card is untrusted input
Consumers MUST treat free text, URLs, files and extension fields as untrusted input.
An AI system MUST NOT execute instructions found in descriptions, evidence documents or linked pages merely because they appear in a Business Card.
23.2 Domain and entity impersonation
Publishers and consumers SHOULD verify:
control of the publishing domain;
consistency between domain, legal entity and identifiers;
redirects to different registrable domains;
registry and trademark references;
the identity of the RFQ operator and contracting entity.
23.3 Authentication and authorisation
Public discoverability does not grant action authority.
Every protected interface MUST use an appropriate authentication scheme. Every material commercial action MUST additionally check authorisation, scope and mandate.
No API key, password, private token or confidential credential may be embedded in the public card.
23.4 Remote resource risks
Consumers that retrieve linked evidence, schemas or interfaces SHOULD defend against:
server-side request forgery;
malicious redirects;
oversized files;
decompression bombs;
active content;
malware;
reference cycles;
unsafe Markdown or HTML;
stale DNS and certificate changes.
23.5 Automation and transaction risk
Agent-actionable and transactional implementations SHOULD provide:
authenticated identities;
explicit mandates and limits;
confirmation steps;
idempotency controls;
audit logs;
error recovery;
revocation;
dispute and escalation routes;
separation between quotation, order and payment authority.
24. Extensions
24.1 Extension object
Extensions MUST be placed under the “extensions” object.
Extension keys SHOULD use an absolute URI controlled by the extension owner or another collision-resistant namespace.
24.2 Consumer behaviour
A consumer:
MUST ignore an unknown optional extension safely;
MUST NOT reinterpret a core field through an extension;
MUST reject or defer an operation when an unknown extension is explicitly marked as required;
SHOULD preserve unknown extension data when forwarding an unchanged card.
24.3 Future vocabularies
Likely extension areas include:
regulated industry data;
sustainability and Digital Product Passport links;
cybersecurity and software supply-chain declarations;
logistics and location availability;
production-capacity exchanges;
supplier diversity;
financing and insurance eligibility;
agent mandate and transaction policy.
25. Validation
25.1 Validation layers
A validator SHOULD perform five separate checks.
1. Syntax validation
valid UTF-8 JSON;
no duplicate property names;
valid data types;
required fields present;
valid date, language, country and URI formats.
2. Schema validation
conformance with the DirectRFQ v0.1 JSON Schema;
controlled vocabulary validation;
extension placement;
conditional requirements.
3. Semantic validation
card identifier and canonical URL are consistent;
subject identifiers refer to the described entity;
roles have scope;
references resolve within the document;
at least one offering or capability exists;
at least one contact or RFQ route exists;
profile claims match populated fields.
4. Trust and freshness validation
claim status and verification status are not conflated;
material claims have evidence where required by the declared profile;
verification scope is explicit;
dates have not expired;
interfaces and links were checked within the declared period.
5. Operational validation
public URLs resolve safely;
RFQ route accepts the declared method;
authentication documentation is available;
confirmation and human escalation work as described;
retired interfaces are not advertised as active.
25.2 Validation result
A validation report SHOULD include:
specification version;
card version;
validator name and version;
validation time;
passed profile;
errors;
warnings;
unresolved external checks;
explicit statement that validation is not supplier approval.
25.3 Error severity
| Severity | Meaning |
| error | Prevents conformance with a claimed profile |
| warning | Does not necessarily prevent conformance but may reduce reliability |
| information | Implementation or quality recommendation |
26. Readiness levels
The DirectRFQ maturity model is informative but provides a common way to describe implementation progress.
Level 1 — Business Listed
The company has a canonical identity, public page, machine-readable core record and responsible publisher.
Level 2 — Entity Verified
Selected identity data and material business claims have been checked against declared sources.
Level 3 — Agent Qualifiable
An agent can evaluate potential fit using structured roles, markets, capabilities, constraints, qualification rules and evidence.
Level 4 — Direct RFQ Ready
The company publishes one or more structured RFQ routes with required inputs, validation and response semantics.
Level 5 — Agent Actionable
An agent can invoke a structured website or API action through WebMCP, OpenAPI, MCP or another documented interface.
Level 6 — A2A Enabled
The company operates or formally appoints an operational agent with a valid technical A2A Agent Card and compatible endpoint.
Level 7 — Agent Transactable
An authorised agent can perform defined commercial actions within a documented identity, mandate, approval, risk and audit framework.
A publisher MUST NOT claim a readiness level solely because it has published the label.
27. Minimal conforming example
The following example is informative and intentionally compact.
{
“type”: “A2ABusinessCard”,
“specificationVersion”: “0.1”,
“cardId”: “https://example-industrial.com/id/business-card”,
“cardVersion”: “1.0.0”,
“status”: “active”,
“canonicalUrl”: “https://example-industrial.com/company/a2a-business-card”,
“machineReadableUrl”: “https://example-industrial.com/a2a-business-card.json”,
“issuedAt”: “2026-07-20T08:00:00Z”,
“updatedAt”: “2026-07-20T08:00:00Z”,
“nextReviewAt”: “2026-10-20T08:00:00Z”,
“language”: “en”,
“profiles”: [
“Core”,
“Discoverable”
],
“subject”: {
“legalName”: “Example Industrial Systems Ltd.”,
“entityType”: “legalEntity”,
“registeredCountry”: “PL”,
“identifiers”: [
{
“scheme”: “nationalCompanyRegister”,
“value”: “EXAMPLE-000001”,
“country”: “PL”
}
],
“website”: “https://example-industrial.com”,
“status”: “active”
},
“commercialRoles”: [
{
“roleId”: “role-integrator”,
“role”: “systemsIntegrator”,
“appliesTo”: [
“end-of-line packaging systems”
],
“territories”: [
“PL”
]
}
],
“markets”: {
“countriesServed”: [
“PL”
],
“industries”: [
“manufacturing”,
“logistics”
],
“languages”: [
“pl”,
“en”
]
},
“offerSummary”: [
{
“offeringId”: “category-packaging-lines”,
“type”: “category”,
“name”: “End-of-line packaging lines”,
“category”: “industrial packaging automation”,
“commercialRoleRefs”: [
“role-integrator”
],
“url”: “https://example-industrial.com/solutions”
}
],
“contactPoints”: [
{
“contactId”: “contact-rfq”,
“purpose”: “RFQ”,
“department”: “Commercial Engineering”,
“channels”: [
{
“type”: “webForm”,
“url”: “https://example-industrial.com/rfq”
}
],
“languages”: [
“pl”,
“en”
],
“accessLevel”: “public”,
“status”: “active”
}
],
“governance”: {
“subjectBusiness”: “https://example-industrial.com/id/legal-entity”,
“dataOwner”: “Example Industrial Systems Ltd.”,
“publisher”: “Example Industrial Systems Ltd.”,
“correctionContact”: “https://example-industrial.com/data-corrections”,
“jurisdiction”: “PL”
},
“accessPolicy”: {
“defaultLevel”: “public”
}
}
28. Extended Direct RFQ example
This example shows the structure of an RFQ route. It is not a complete card.
{
“routeId”: “rfq-packaging-line”,
“name”: “Packaging line selection and quotation”,
“intent”: “solutionSelection”,
“appliesTo”: [
“category-packaging-lines”
],
“channelType”: “webForm”,
“endpoint”: “https://example-industrial.com/rfq/packaging-line”,
“method”: “POST”,
“requiredInputs”: [
{
“fieldId”: “productType”,
“label”: “Product to be packed”,
“dataType”: “string”,
“required”: true
},
{
“fieldId”: “throughput”,
“label”: “Required throughput”,
“dataType”: “number”,
“unit”: “packs/hour”,
“required”: true
},
{
“fieldId”: “installationCountry”,
“label”: “Installation country”,
“dataType”: “countryCode”,
“required”: true
}
],
“optionalInputs”: [
{
“fieldId”: “layoutFile”,
“label”: “Production layout”,
“dataType”: “file”,
“required”: false,
“confidentialityClass”: “confidential”
}
],
“acceptedFiles”: {
“mediaTypes”: [
“application/pdf”,
“image/jpeg”
],
“maximumFileSizeMB”: 20
},
“authentication”: {
“type”: “none”
},
“humanReview”: {
“required”: true,
“role”: “applicationEngineer”,
“triggers”: [
“nonStandardProduct”,
“regulatedEnvironment”,
“missingSafetyData”
]
},
“expectedResult”: “qualificationResponseOrQuotation”,
“responseTarget”: {
“value”: 2,
“unit”: “businessDays”,
“type”: “objective”
},
“termsUrl”: “https://example-industrial.com/rfq-terms”,
“privacyUrl”: “https://example-industrial.com/privacy”,
“status”: “active”
}
29. Implementation checklist
Phase 1 — Core record
Resolve the legal entity, brands, domains and contracting relationships.
Select a stable card identifier and canonical page.
Add official organisation identifiers.
Declare commercial roles and their scope.
Summarise offerings and capabilities.
Identify markets, territories and exclusions.
Add durable contact points.
Assign data owner, publisher and correction contact.
Publish version and freshness information.
Generate and validate the JSON record.
Phase 2 — Evidence and qualification
Identify material claims.
Attach evidence references.
Record verification scope and status.
Define fit criteria and exclusions.
Define required buyer inputs.
Define information-gap and human-review triggers.
Review privacy and access levels.
Phase 3 — Direct RFQ
Separate RFQ routes by commercial intent.
Define required and optional inputs.
Add validation, files and confidentiality rules.
State the expected result and response target.
Define human escalation.
Test submission, acknowledgement and routing.
Phase 4 — Agentic interfaces
Publish machine-actionable form semantics where justified.
Add WebMCP, OpenAPI or MCP only for operational implementations.
Link a technical A2A Agent Card only when an A2A server exists.
Define authentication, mandate and confirmation.
Add monitoring, audit and revocation.
30. Conformance statement template
Publishers MAY use the following statement:
This document conforms to the DirectRFQ A2A Business Card Specification v0.1 at the declared profile level. Conformance indicates structural compliance with the specification. It does not constitute supplier approval, independent verification of every claim, a binding commercial offer or authority for an AI agent to enter into a transaction.
The statement SHOULD identify:
card version;
claimed profiles;
validation date;
validator;
data owner;
publisher;
last verification date;
correction route.
31. Frequently asked questions
Is this an official Agent2Agent Protocol specification?
No. It is an independent DirectRFQ business-data specification. It complements the technical Agent Card defined by the Agent2Agent Protocol but is not part of that protocol.
Does a company need an AI agent to publish a Business Card?
No. A company may publish a Core, Discoverable, Evidence-Linked, Agent-Qualifiable or Direct-RFQ-Ready card before deploying an AI agent.
Is a published card proof that the company is verified?
No. Verification applies only to the claims and scope explicitly marked as checked. Publication alone is not verification.
Is a Business Card a supplier approval?
No. Buyers may still require due diligence, onboarding, financial review, security assessment, compliance documentation and contractual approval.
Can prices, stock and lead times be included?
Yes, but time-sensitive data must include its scope, update time, validity, currency, unit and conditions. Separate offer or Product Card records are usually better.
Can confidential evidence be referenced?
Yes. The public card may describe the evidence and access conditions without exposing the document.
Does Direct RFQ mean that a quotation is automatic?
No. A Direct RFQ route standardises the enquiry. The supplier may still require technical review and may decline to quote.
When may the card claim A2A Enabled status?
Only when the company operates or formally appoints an operational agent with a valid technical A2A Agent Card and compatible endpoint.
Can an agent place an order using the card?
Not by default. Transaction authority requires separate identity, mandate, approval, security, audit and contractual controls.
Does conformance guarantee visibility in AI systems?
No. Conformance improves clarity, interoperability and agent readiness, but external systems decide what they discover, cite, rank or recommend.
32. Governance of the specification
DirectRFQ.com is the specification owner for version 0.1.
Future development SHOULD include:
a public JSON Schema;
machine-readable controlled vocabularies;
example cards for multiple B2B sectors;
a conformance validator;
an extension registry;
change proposals and issue reporting;
implementation reports;
migration guidance for later versions.
A future specification version SHOULD document:
additions and removals;
changed field semantics;
deprecated fields;
compatibility impact;
migration steps;
security implications.
33. References
Agent2Agent Protocol Specification 1.0
A2A project under the Linux Foundation
RFC 2119 — Key words for use in RFCs
RFC 8174 — Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
RFC 3339 — Date and Time on the Internet
RFC 8785 — JSON Canonicalization Scheme
WebMCP specification repository
Google: Agentic Resource Discovery
W3C Verifiable Credentials Data Model 2.0
34. Publication notes for DirectRFQ.com
Recommended page title
A2A Business Card Specification v0.1
Recommended subtitle
The canonical DirectRFQ specification for structured, verifiable and agent-ready business identity.
Recommended URL
/specifications/a2a-business-card/v0-1/
Meta title
A2A Business Card Specification v0.1 | DirectRFQ
Meta description
The canonical DirectRFQ A2A Business Card v0.1 specification for business identity, capabilities, evidence, qualification and agent-ready RFQ routes.
Primary keyword
A2A Business Card Specification
Supporting keywords
A2A Business Card schema;
agent-ready business identity;
machine-readable company profile;
AI supplier qualification;
Direct RFQ specification;
A2A Business Card JSON;
agentic commerce standard;
B2B business data for AI agents.
Recommended structured data
TechArticle;
DefinedTerm;
Organization;
BreadcrumbList;
FAQPage where eligible under the publishing platform and search-engine policy.
Recommended downloadable assets
A2A Business Card JSON Schema v0.1;
minimal JSON example;
extended Direct RFQ example;
conformance checklist;
controlled vocabulary file;
change log;
printable PDF;
editable Word version.
Editorial decisions required before public release
DirectRFQ.com should decide and publish:
the final canonical URLs;
reuse and implementation licence;
issue-reporting channel;
schema repository;
validator status;
trademark and naming policy;
public change-management process.
For broad adoption, a practical option is an open documentation licence for the specification text and a permissive software licence for schemas, examples and validators. The final licence must be selected and approved by DirectRFQ.com before publication.
Start a Direct RFQ Project
Opening
Prepare your company, product, capability or purchasing workflow for AI-assisted B2B discovery and agentic commerce.
Project types
You can contact Direct RFQ about:
- an A2A Product Card;
- an A2A Business Card;
- an A2A Capability Card;
- a Direct RFQ Card;
- an A2O readiness review;
- an agentic commerce assessment;
- a structured data or card library project.