specs/credentials/shared/v0_2/credentials library

Classes

IssuedCredentialBase: The members of an issuance receipt, deliberately left open so a consuming specification can $ref it under allOf and add its own, then close the result with unevaluatedProperties: false. A closure inside this definition would defeat that. Both additionalProperties and unevaluatedProperties are evaluated against the whole instance from within the subschema that declares them, and neither can see members the outer schema matched — so either one here rejects the consumer's extras. Only an unevaluatedProperties at the outer level sees everything the composition matched. Use IssuedCredential where a closed standalone shape is wanted.
RevocationReceipt: The receipt for a successful revocation. Consumers MUST report the family's alreadyRevoked / already_revoked error when the credential was already revoked, rather than returning a second receipt silently — the caller has to be able to distinguish "I revoked it now" from "it was already gone". The counterpart to IssuedCredential: both concern a credential's lifecycle at its issuer.

CredentialId = String: Stable identifier for an issued credential — the handle for revocation and audit. Opaque to the holder: it MUST be echoed verbatim when revoking and MUST NOT be parsed.
IssuedCredential = Object?: The receipt for a successfully-minted Verifiable Credential: a stable handle for revocation and audit, the signed credential itself, and when it lapses. Closed — unknown members are rejected. SCOPE — an issuance receipt, returned by the party that minted the credential. Not the shape for a delivery receipt, where a holder hands an already-issued credential to a party that stores it: such a task returns a receipt naming what was stored (see vtc/members/vmc and vtc/join-requests/accept) and MUST NOT echo the credential back to the party that just sent it. A specification needing extra members composes IssuedCredentialBase instead and closes at its own level; see vta/credentials/issue/0.2.