Credential content

Overview

When a credential is issued, its claims are assembled from two sources: the user's attributes stored in the database, and the organization's VC profile, which maps those attributes to named claims in the credential subject.

User attributes

Each user in an organization has a set of typed attributes (string, integer, boolean) stored in the database. Attributes are loaded via CSV import — each column becomes an attribute, identified by its column name.

The attribute names used in the CSV become the field names referenced in the VC profile.

VC profile

Each organization has a VC profile that controls which attributes appear as claims and under what names. The profile is a JSON file that contains a subject_template object:

{
  "profile_id": "default",
  "subject_template": {
    "displayName": "${org_user_data.fullName}",
    "mail": "${org_user_data.email}",
    "employeeID": "${org_user_data.userName}"
  }
}

Each key in subject_template becomes a claim name in the issued credential. Each value is an expression referencing a user attribute by its name in org_user_data. Attributes not referenced in the template are not included in the credential.

Caution

displayName is a required key in subject_template. The server validates this at startup and refuses to start if the mapping is absent. At issuance time, if the referenced attribute is empty for a particular user, credential creation fails with a descriptive error. The CSV column that supplies this value can be named anything — the template expression is the only place the mapping needs to be defined.

The profile may also contain a type_metadata block with display labels and per-claim metadata. Each entry in type_metadata.claims can include:

• display — localized label shown in the wallet UI
• sd — the claim's disclosure policy per the SD-JWT VC spec
• mandatory — whether the claim is required to be present

The sd and mandatory fields are informational — the server makes every claim in the credential subject selectively disclosable unconditionally, regardless of the sd value. type_metadata does not control which claims are issued or their values; it is metadata for wallets and verifiers about how to present and interpret the credential.

The attribute name chain

The same attribute name flows through three configuration layers. Keeping them in sync is the most common source of misconfiguration.

Layer	Where the name appears	Role
CSV import	Column header	Becomes the key in org_user_data
organization_person_columns[n].key	Settings in the org config	Controls which attributes appear in the admin user search UI
subject_template value expression	${org_user_data.<name>}	Maps the attribute to a named VC claim

A single attribute named fullName in the CSV would appear across all three as follows:

fullName,email
Anna Andersson,[email protected]

"organization_person_columns": [
  { "key": "fullName", "header": "screen3.col_fullName" }
]

"subject_template": {
  "displayName": "${org_user_data.fullName}"
}

The VC claim is named displayName — the template controls the output name independently of the input attribute name. If the CSV column were renamed from fullName to name, both organization_person_columns and the subject_template expression would need to be updated to match.

Automatic claims

Two claims are always added to the credential subject regardless of the template:

Claim	Value
organizationID	The organization's external identifier
assuranceLevel	loa3 or loa4, derived from the security class of the application

These claims are added to the credential subject automatically and are selectively disclosable in the issued credential. They are not added automatically to type_metadata.claims — if you want them to appear in the wallet UI with display labels, include entries for them in the profile's type_metadata.claims array alongside the template-rendered claims.