Skip to content

Verifiable Credentials: high level feature requirements

Jump to bottom Edit New page
Volodymyr Bergman edited this page Feb 16, 2023 · 2 revisions

Open edX Verifiable Credentials

Verifiable Credentials is a specific kind of digital credentials with a standardised data model and life cycle.

Generic meaning of verifiable credentials include the Verifiable Credentials (data model, VC-DATA-MODEL) itself and its derivatives (e.g. Open Badges 3.0 and other standards that are compatible with VC-DATA-MODEL but have implementation specifics and extensions).

The feature is aimed to gain the OeX ecosystem capabilities to issue verifiable credentials based on internal credential types.

General requirements

Code base involved

Code base updates are planned at least to the following repos:

  • OeX Credentials
  • OeX Learner Record MFE
  • (possibly) new repo(s) for pluggable extension(s)

OeX Credentials

The core functionality must be placed as an another OeX Credentials application named verifiable_credentials (e.g. credentials.apps.verifiable_credentials.

OeX Learner Record MFE

Additional UI will appear within the Learner Record MFE (currently optional, under development) as a separate page (or tab). Needs specification.

TODO: (2023-02-13) create ADR that describes RaccoonGang's vision on LRMFE re-organisation (components/routing/structure) from the perspective of the new functionality.

New repo(s) for pluggable extension(s)

Some pieces of functionality may be extracted into a separate plugins.

Currently, it could be:

  • NoWallet (simple, Django-based wallet backend to request verifiable credentials for visualisation/downloading)
    • development/testing purposes;
    • onboarding/trial purposes;
    • plugins proof;
    • multi-wallet proof;

TODO: (2023-02-13) share basic NoWallet concept with tCril.

Optionality

The Verifiable Credentials feature must be implemented as completely optional for usage (hidden under feature flag). Ideally, a single configuration (deployment configuration aware) flag must make unavailable any related component, e.g. API endpoints, UI elements, admin interfaces, etc.

Multiple issuers support

Verifiable credential is issued by an Issuer. Such Issuer is "backed in" verifiable credential via its content and a proof. Within an OeX installation there must be a mechanism to setup:

  • per site/organisation issuer (used for site/org related OeX user credentials);
  • default (instance/installation level) issuer (used as a last resort);

DECISION: (2023-02-13) proceed with default system-wide config only (single issuer per installation).

OeX credential types support

Currently OeX Credentials service has implemented user credentials for Program Certificates only (keeping in mind Course Certificates transfer intension).

Verifiable credentials are expected to be created for OeX Program Certificates exclusively for now.

  • There must not be blockers to extend verifiable credentials issuance for any kind of OeX credential type in the future.

Decentralised Identifiers (DIDs) generation support

There is a separate specification for Decentralised Identifiers with use cases defined. DIDs are used in verifiable credential as identifiers for:

  • issuer
  • credential subject

Issuer DID(s) must be provided already generated (e.g. created out of OeX); Credential Subject DID must be provided as a part of incoming issuance data (e.g. storage responsibility);

No DIDs generation support is expected.

DECISION: (2023-02-13) proceed with "expert" mode (DIDs are prepared in advance).

Signing keys generation support

Any verifiable credential cryptographic proof type relies on keys. Keys are used for:

  • issuer DID generation
  • credential signing (proof generation)

Keys generation is out of OeX responsibilities (e.g. keys are created out of OeX);

DECISION: (2023-02-13) proceed with "expert" mode (keys are prepared in advance).

Data models support

There are several already described (detailed via a standard/specification) data models for verifiable credentials:

  • Verifiable Credentials - eponymous data model specification;
  • Open Badges 3.0 - based on Verifiable Credentials with its specifics and extensions (achievements/badges/skills focused), incompatible with previous Open Badges revision;
  • ... (highly growing field)

This implementation is focused on a support of Open Badges 3.0.

  • Implementation should allow extending other data models support in the Future (see: "Functionality extension points").
  • Implementation should allow a work of different data models simultaneously (based on storage preferences).

DECISION: (2023-02-13) we'd like to have implemented options for both VC & OBv3 (at least, in "switch" mode).

Digital storages support

There are a plenty of already implemented digital wallets/vaults that allow digital credentials storing. Some of them are implemented as web services, some - as native mobile applications.

This implementation is focused on the integration with the Learner Record Wallet which provides mobile application (Android, IOS) for storing verifiable credentials. It is compatible with Open Badges 3.0.

  • Implementation should allow extending other data models support in the Future (see: "Functionality extension points"). (see: "Functionality extension points").
  • Implementation should allow a work of different storages simultaneously (based on learner preferences/choice).

TODO: (2023-02-13) provide UI/UX design for multiple wallets buttons option.

Web services vs native applications

Some storages (wallets) are expected to be implemented as a native mobile app, when others are web services. Issuance pipelines can vary for those.

DECISION: (2023-02-13) we'd like to support both types of pipelines.

Credential expiration support

Verifiable credentials expiration support is expected.

DECISION: (2023-02-16) Expiration period of time should be extracted to the deployment configuration. No expiration by default.

Credential refreshing support

No verifiable credentials refreshing support is expected.

DECISION: (2023-02-16)refreshing allows previously suspended verifiable credential to be valid again. Since there is no evidenсe of the suspension use case in OeX Credentials. New verifiable credential issuance works instead.

Multiple credentials support

Only single credential support for verifiable credentials is expected.

DECISION: (2023-02-16) a single verifiable credential may include multiple credentials (e.g. 2 and more earned OeX Program Certificates). Currently, we'll include a single user credential per a verifiable credential only.

Signing services support

There are implementations that delegate signing/verification activities for verifiable credentials to an external services.

It is not planned to support external signing service(s) for now. Signing procedure is expected to be implemented within the OeX Verifiable Credentials internally.

Multiple proofs support

There are at least 2 kinds of proof specified (can be used together):

  • external
  • embedded (LD proof)

DECISION: (2023-02-16) OeX Verifiable Credentials are expected to use embedded proof only, for now.

Multiple Linked Data proof formats support

A set of Linked Data proof formats (now and in the Future) can be used for signing verifiable credential.

It is expected to support Ed25519 Signature 2020 only. No multiple formats support for now.

Status verification support

Status verification allows verifiers to ensure verifiable credential is still active/valid (not revoked/suspended). Status verification is optional (based on specs). There are different specifications/approaches.

Verifiable credentials are expected to use Status List 2021 approach.

Verifiable credentials revocation support

Sometimes issued verifiable credentials need to be invalidated (for different reasons).

There must be a way to revoke issued verifiable credentials based on OeX internal triggers (e.g. learner's Program Certificate changes its status to "revoked").

Verifiable credentials suspension support

No verifiable credentials suspension support is expected. See "Credential refreshing support".

Functionality extension points

  • multiple data models support - OeX Credentials must be able to produce (issue) verifiable credentials based on both Verifiable Credentials and Open Badges 3.0 data models, and should be ready to be extended with other data models in the Future;
  • multiple storages support - OeX Credentials must be ready to store (init wallet/vault-specific deep links, authenticate and process wallet/vault-specific issuance requests) verifiable credentials in different compatible storages (wallets/vaults) mobile/web based;

Future considerations

  • multiple issuers support - OeX Credentials should be able to produce (issue) verifiable credentials on behalf of different logical issuers (Site/Organization/Course levels);
  • additional proofs support - OeX Credentials should be able to produce (issue) verifiable credentials with proofs in different formats;
  • multiple signing services support - OeX Credentials should be able to produce (issue) verifiable credentials with the help of different (including external) services;

References

Add a custom footer
Add a custom sidebar
Clone this wiki locally