Template management

[daniel-mader]

Description

In order to issue credentials more efficiently and to provide more guidance for users, a credential templating system is proposed.

Data model

The data model for a template should include:

• id: unique identifier, generated by UniCore
• name: display name for easy reference
• description: (optional) description of what the template is used for and what it contains
• version: number meant to be incremented by UniCore on every change of the data (not metadata)
• logo_url: (optional) a URL to the logo of the credential
• creator
  • name: display name of the creator of the template
  • url: URL of the credential issuer who created the template
• holder_type: either individual or organization to indicate whether this template is meant for B2C or B2B issuance
• created_at: should never change after initial creation
• last_modified_at: a timestamp when the template was edited or a new version was pulled from the original creator
• tags: (optional) a set of strings to allow quick reference for searching and grouping, limitations (such as max. length of each tag or the total number of allowed tags are to be discussed)
• data
  • template: a json object compliant with a credential data model (such as W3C v1.1, Open Badges 3.0, etc.) which also contains placeholders in the form of strings following the mustache convention (example: "first_name": "{{FIRST_NAME}}")
  • placeholders: JSON Schema where the "properties" are used to fill the placeholders in the template. No business restrictions need to be enforced in UniCore, only a check if the JSON Schema is according to standard.

Commands

• AddTemplate (providing the full data model as described above, except the values generated by UniCore)
• GetTemplates (optional: filter by holder_type)
• UpdateTemplate (providing any part of the data model above will patch the existing data)
• RemoveTemplate
• CloneTemplate (copies the entire object, generates a new UUID, appends "Copy" to the name)

HTTP API endpoints

• /v0/templates
  • POST: AddTemplate, DuplicateTemplate (indicated via a body such as {"duplicate_from": "<uuid>"})
  • GET: GetTemplates
  • DELETE: RemoveTemplate
  • PATCH: UpdateTemplate

Further requirements & considerations

1. (Cheyenne) Add raw issuance in dev mode:
   Toggle raw issuance in dev mode: Flag SKIP_TEMPLATE_ENFORCEMENT which defaults to false.
2. (Cheyenne) Add RemoveTemplate and DuplicateTemplate endpoints
3. Add hardcoded json schemas and Validation (see Oran’s PR - identity-wallet/src/state/core_utils/helpers.rs pub fn validate_credential_against_schema.
4. (Nander) Derive CredentialConfig from Template:
   a) PR 1: Date Conversion: Template type -> credential config (data conversion)
   b) PR 2: Communication between Issuance and Library domain
5. (Cheyenne) add public boolean field & add template Status: draft - active - archived - deleted
6. Versioning of templates: semantic

Hashing

To make synchronization of templates across different systems easier and less error-prone, UniCore should be able to check for content drift between different template objects by calculating the hash (canonicalization (JCS) should happend before calculating the hash). This gives additional safety, since the version could drift and can not be synced reliably.

Edit limitations

No template should be modifiable that was created by a different party. If modifications are desired, a duplication is suggested by the frontend. This will be further described in a separate issue regarding template sharing.

Motivation

More convenient and less error-prone credential issuance.

Requirements

See description

Open Questions

No response

Are you planning to contribute this in a PR?

Yes