Ayra Protocol: Interactions

The Ayra Protocol defines a small number of interactions that standardize how trusted relationships begin. It has no opinion on what follows.

What the Ayra Protocol Standardizes

The Ayra Protocol standardizes the start of trusted interactions between parties. Think of it as the first couple of dance moves: once both parties know the same opening sequence, they can quickly discover what kind of relationship they're entering and get on with their business.

The protocol defines three core interactions:

1. Connect — establish a trusted channel between two parties

2. Present credential — share an Ayra Card (badge, business card, or other credential type)

3. Access payloads — pull specific payloads from the credential

After these opening moves, the Ayra Protocol steps back. How you use the channel, what business you conduct, what additional data you exchange — that is yours. Ayra has an opinion on how the dance starts. We do not have an opinion on the dance moves that follow.

The Three Core Interactions

1. Connect

Two parties establish a trusted, encrypted channel using DIDComm 2.1. This is the digital equivalent of walking up to someone and introducing yourself — except the introduction is cryptographically secured.

What happens:

• Party A initiates a connection (via QR code, deep link, or agent-to-agent discovery)

• Party B accepts the connection

• Both parties now have a private, persistent channel

What the protocol requires:

• The connection uses DIDComm 2.1

• Both parties have resolvable DIDs (default: did:webvh)

• The channel is encrypted end-to-end

What the protocol does NOT require:

• Any specific reason for connecting

• Any specific information to be shared at connection time

• Any particular user experience or interface

2. Present Credential

Once connected, either party can present an Ayra Card credential. This is the "show me your badge" or "show me your business card" moment — a consistent, repeatable interaction regardless of the ecosystem, industry, or use case.

What happens:

• One party offers or requests an Ayra Card credential

• The credential is presented and cryptographically verified

• The verifier confirms the credential against the Trust Registry (via TRQP)

What the protocol requires:

• The credential conforms to the Ayra Card schema (W3C VCDM 2.0)

• The issuer is registered in a Trust Registry that is recognized by the Ayra Trust Network

• The double-link is present: credential → ecosystem Trust Registry → Ayra Trust Network

• The holder controls presentation (selective disclosure where applicable)

What the protocol does NOT require:

• Any specific credential type (Business Card, Staff Pass, or future types all work)

• Any specific action to be taken after verification

• Any particular business logic about what a verified credential means for the verifier

3. Access Payloads

Payloads are the content that makes a credential valuable beyond the card itself. Once a credential is presented, the verifier can request specific payloads carried by that credential.

A payload is not just data. It can be one of three things:

• Simple data — a certification level, a role, an email address, a booking link. Unverifiable but useful.

• A credential in its own right — a verifiable presentation backed by an independently issued credential. A professional license, a security clearance, a competency validation.

• A pointer — "come check me out over here." A payload that directs the verifier to a source they would never have known to look at on their own. A learning record at an assessment provider. A government registry. An AI agent endpoint. The person decides what to share and where to send the verifier.

Pointers are what make the individual the integration point. A verifier doesn't need to know in advance which government issued your ID or which institution holds your learning record — the payload tells them where to look.

What happens:

• The verifier requests one or more payloads from the presented credential

• The holder consents to sharing the requested payloads

• Payload data is delivered over the established channel (or, for pointers, the verifier follows the pointer to the indicated source)

What the protocol requires:

• Payloads conform to the Ayra payload architecture (see Payloads)

• The holder explicitly consents to each payload disclosure

• Payload delivery uses the established trusted channel

What the protocol does NOT require:

• Any specific payload types or content

• Any specific action to be taken with received payload data

• Any ongoing relationship or repeated exchange

After the Opening Moves

Once connection, credential presentation, and payload access are complete, the parties have what they need to proceed with whatever business brought them together. The Ayra Protocol is done.

The channel remains available. The parties may:

• Continue exchanging information over the same channel

• Request additional payloads at a later time

• Use the channel for business-specific workflows

• Close the connection

None of this is prescribed by the Ayra Protocol. The protocol solved the hard problem — how do two parties who have never interacted before establish trust quickly, verify each other's credentials, and access the information they need — and then gets out of the way.

What This Means in Practice

These interactions work across any boundary that blocks integration today — not just between companies, but between departments within a company, between companies and governments, between ecosystems that don't know each other exists.

Crossing internal boundaries: An employee presents their Ayra Card (employee badge) at a facility managed by a different business unit. The facility verifies the credential against the Trust Registry, pulls the relevant payload (access authorization, security clearance level), and grants or denies access. Engineering, legal, and finance don't need to coordinate a bespoke integration — the protocol handles the trust boundary.

Crossing company boundaries: A professional shares their Ayra Card (business card) with a new contact at another organization. The contact's system verifies the credential, pulls payloads (role, organization, relevant certifications). The Ayra Protocol established the trusted connection. What they do with it — schedule a meeting, start a partnership, exchange further information — is their business.

Crossing ecosystem boundaries: An employer verifies a job candidate's Ayra Card carrying an education certification. The protocol verifies the credential, confirms the assessment organization is an authorized issuer via the Trust Registry, and delivers a pointer payload — "come see my learning record here." The employer follows the pointer to a portfolio they would never have found on their own. The Ayra Protocol bridged the education ecosystem and the employment ecosystem through the individual.

Crossing company-to-government boundaries: An immigration firm verifies a worker's professional qualifications. The Ayra Card carries a pointer payload to the licensing authority's registry. The firm didn't need a bilateral integration with that government body. The worker's credential told them where to look.

Interactions Currently Out of Scope

The following interaction patterns are acknowledged but not currently defined by the Ayra Protocol:

• 1:N presentations — one holder presenting to multiple verifiers simultaneously

• N:1 collection — multiple holders presenting to a single verifier in a coordinated flow

• N:N exchanges — group interactions (forums, communities, multi-party negotiations)

• Ongoing subscription — automatic payload updates pushed to a verifier over time

These patterns may be addressed in future versions of the protocol as the trusted channel infrastructure matures and real-world usage patterns emerge from pilots.

Relationship to Other Concepts

• The Dance — the metaphor that frames these interactions. See The Dance for the full analogy.

• Payloads — the extensible content architecture. See Payloads for payload types and categories.

• Credential Types — the credential family. See Credential Family for Business Card, Staff Pass, and future types.

• Conformance Test Suite — validates that implementations correctly execute these interactions. See Components & Specs.