Payload Types

PayloadTypes

The Ayra Cards concept allows for an arbitrary list of Payloads to be shared in an Ayra Cards. Initially they will not be widely known nor managed/governed.

Over time payload types should provide signalling about what is supported (or not). This is analogous to GetCapabilities() in the GIS realm and _______ in the COM/ActiveX realm - which allows interrogation and discovery of base capabilities.

IDEA: COM "failed" (as in didn't go global) due to limitations. GUID registration was at a local registry level, which made systems integration hard. A DID-based approach could overcome this limitation in that it could define service endpoints by identifier - which could be managed in a (decentralized?) registry/type catalogue.

Example/Notional Types

• bookinglink - a Calendly-style link for booking meetings with the bearer.

• ai_assistant_a2a - an A2A (perhaps over DIDComm/TSP) endpoint .

• vendor:special - an example of an opaque payload (i.e. one that most won't understand but iykyk).

Known/Unknown and Managed/Unmanaged

• Unknown payloads are those that have no shared definition in the community. The consumer (verifier) of an unknown payload may understand what it is from the information received, but that is entirely up to them.

  • useful for private payloads where the context and content are understood implicitly by the creators and consumers of the payload.

• Known payloads are those that have some kind of payload definition. These may be:

  • Unmanaged - informal payload types

  • Managed - formally managed payload types

More detail below.

UNKNOWN & UNMANAGED Payloads

By default any Payload object can be supported, within the constraints of the credential format (W3C VCDM2). No formal coordination is required, especially in the beginning of Ayra Cards.

KNOWN & UNMANAGED Payloads

The first step to formalizing is to provide an informal Payload description so the Ayra community can understand what a particular payload is, how it works, when it should be used, what to do when it appears, etc.

This stage will be informally managed (e.g. in a public github repository) and have very lightweight process. Consider the DID Method registration process as an exemplar of this kind of lightweight process.

This stage is likely characterized as the point where we start to have collision of payload types and a payload definition becomes helpful to deconflict. Imagine multiple ecosystems applying a "verified_email" payload type

KNOWN & MANAGED

In the (near?) future there managed payloads, that the community understands at an ecosystem level. The goal being that integrators can re-use the approaches and that they can be formalized (i.e. specified and testable).

This stage will have heavier process and will only likely be used for payloads that are either very high volume, or high value.

Managed payload types will likely:

• have rigourous procedures for managing the types

• have deconfliction and namespacing

• have terms & conditions that apply

• have conformance criteria

• ...