Components & Specs

Early exploration of the key components for Ayra Card.

Trust Registry

The Trust Registry will support TRQP 2.0 (PR02) and the Ayra Extensions

• SPECIFICATION: TRQP 2.0 PR02

• + Ayra Profile - to be finalized before end-September

  • The Ayra Profile creates a Swagger (and DIDComm?) capability for the basic queries that allow for "discovery". Examples include:

    • list the authorizations used in this TR;

    • list the TRs you recognize;

    • list the entities in your ecosystem

  • NOTE: This is NOT a discovery layer - but provides the data that would populate such a layer.

Ayra Card Credential Types

• Type: W3C VCDM2.0

• Schema - to be set by type (e.g. Business Card, Staff Pass)

Ayra Type Catalogue

The Type Catalogue is an evolving concept. In the initial "The GAN Plan," it was called the "GAN Verifiable Data Types Registry" and described as follows:

The "Type Catalogue" will begin to create some of the capabilities listed above. The Ayra Card initiative will focus on a few aspects:

• Credential Schema Definitions - the data definitions for the Ayra Card credential types (e.g. Business Card, Membership Card, Staff Badge). These will include the schema and information (metadata) about the data and semantics involved.

• Authorizations - as the Ayra Trust Network grows, and more and more ecosystems/networks connect, Ayra may become an important registry of the authorizations that are used in a Trust Registry.

  • Ayra Card requires, in time, tracking of which entities have authority to issue a particular Ayra Card. The Type Catalog will be used to list the authorizations - which will then be used in Trust Registries for mapping an Entity's authorities.

  • Authorizations are managed by the ecosystem. An entity is granted a particular authority as an "assertion_id" in TRQP.

• Payload Type Management - In the earliest stage, payloads are simply data triples, and the "type" of a payload will be unmanaged. There will likely be a short list of "Ayra Managed" types that end up being managed by the Ayra Members or Ayra Association. That means that "Payloads" can be: managed or unmanaged.

• (potentially) Verifiable Presentations - managing the VPs that are "normal" or "authorized" may, in time be needed. example: a proof-of-citizenship VP could be standardized and require management in a particular ecosystem. No work is currently planned on this aspect/

Verifiable Presentations

• Ayra VPs - to be determined (e.g. full business card, desk sign-in, meet-a-person)

  • VPs may, in time, be managed to create simplicity for Verifiers. TODO

FPP Alignment via Verifiable Presenations

• FPP VRC & PHC to be supported as VPs of Ayra Card. For example a "Staff Pass"

  • Can be presented (via VP) to meet BOTH the FPP PHC and FPP VRC requirements

NOTE: On DIDComm & OID4VP

• For presentation of the credential, either can be used but efforts here focus on the DIDComm aspects as there is a persisent, private connection established (between private DIDs) that opens up further use - and the subsequent "dance" that may be required.

• As the credential can be presented via OID4VP using most systems there is no urgent need for integration into the full system.