Invitation Credential (VIC)

A Verifiable Invitation Credential authorizes the onboarding of a new member into a VTC or VTN. It’s the bootstrap mechanism for bringing new participants into the trust graph.

Who Can Invite

The issuer of a VIC depends on community policy:

• For VTC membership: the VTC’s own DID, or an authorized member’s DID (if the community allows member-initiated invitations)
• For VTN membership: the VTN’s DID, or a member VTC’s DID

This flexibility lets communities choose between centralized invitation (only the community itself can invite) and decentralized invitation (existing members can bring in new people). The spec makes explicit that these are two functional variants of one credential — the VTC invitation credential (issued to the identifier the prospect proposes to use in that community) and the VTN invitation credential (issued to a prospective member VTC’s identifier) — distinguished by issuer/subject rules, not by separate type strings. (WD01 said “M-DID” and “C-DID”; WD02 retired those types in favor of correlation-scope.) Since Working Draft 0.6.0 the VIC carries issuerScope like every DTG credential — public where the issuer is the VTC or VTN itself, the member’s own declaration where a member invites. Its Security Considerations add replay guidance: VICs should be issued with short validity periods and treated as single-use by the accepting VTA / Policy Enforcement Point (PEP — the VTC’s policy engine for credential issuance and revocation).

WD01’s open editor’s note — should role or access-control information be embedded in the VIC? — was answered in WD02 (spec PR #29): it should not. What a party may do is conferred by an Authority Credential, which can be re-issued or attenuated without touching the invitation that admitted them; roles and policy are otherwise inferred from the issuer plus the trust registry.

The spec also sketches the identity-proofing path a VIC can start: the VTC issues a VIC to the prospect’s proposed identifier → the prospect proves themselves to an identity verification provider (IDVP — Veriff, Jumio, Yoti and the like are the examples given) → the IDVP issues an identity verification credential (IDVC, not a DTG credential) to that same identifier, which the community’s join policy can then require.

Role in the Ecosystem

In Working Draft 02 the VIC was the sole member of an “Invitation Credentials” category; on 2026-09-10 (closing issue #28) it was promoted to a top-level section, and on 2026-09-22 (WD 0.5.0, #55) the categories went altogether — the VIC is simply one of the four credentials complete on the issuer’s signature, and it bootstraps a node into a community rather than forming an edge. Nothing normative changed. Once the invitee completes onboarding and the VMC pair is formed, the invitation has served its purpose. A data room — a DTG node with its own DID — admits a member the same way: VIC for entry, VMC pair to form the membership edge, then VACs for what the member may do inside.

The PEP processes invitation credentials during the onboarding flow.

Implementation Status

As of June 2026 the VIC is implemented end-to-end, making it the first invitation mechanism to go from spec to working code; by August (OpenVTC v0.3.x / the Cypress release) a pasted VIC pre-fills the community in the join flow, the join can run over TSP, and an applicant can poll a community about an unanswered join. On the community side, the VTC service supports automatic join via VIC — with role-on-invite, revocation, QR-sized invitations in the admin UI, and a verdict-model admission pipeline. On the member side, OpenVTC presents a VIC at join, stores VICs in the VTA credential vault, and supports a subject-linkage proof so an invitee can join under a freshly minted DID different from the one the VIC names. Since Dogwood a pasted VIC must carry the DTG common structure at ingest (openvtc #256), and since Eucalyptus (openvtc #397) it is parsed through dtg-credentials 0.12: v1 context second, issuerScope: public, exactly one concrete type, an object-form issuer refused. The join completes properly — receiving the community’s VMC grant auto-issues the member’s acknowledgement, closing the membership edge (openvtc #259–#267) — and the admitted member’s VMC and role VAC now arrive as separate credential-exchange/issue/0.1 deliveries rather than only in the verdict. The VTC’s own invitations (vtc/invitations/issue) and the VTA rooms’ rooms/owner/invite issue VICs as public under the v1 context. See the Recent Development sections on openvtc and verifiable-trust-infrastructure.

See also: membership-credential, authority-credential, credential-categories, verifiable-trust-community, verifiable-trust-network, data-rooms