`CredentialMetadata` drops `credential_metadata.claims[]`, so wallets cannot show the issuer's published claim names

[mc1100]

Version: observed on 0.99.0; re-checked against main @ 145e9e1a — unchanged.

What happens

OpenID4VCI lets an issuer publish a display name per claim, localized. Here is the real metadata from the EU reference issuer, configuration eu.europa.ec.eudi.pid_vc_sd_jwt — credential_metadata.claims is an array of 31 entries in this configuration alone:

"credential_metadata": {
  "display": [ /* … */ ],
  "claims": [
    { "path": ["family_name"], "mandatory": true,
      "display": [ { "name": "Family Name(s)", "locale": "en" } ] },
    { "path": ["given_name"],  "mandatory": true,
      "display": [ { "name": "Given Name(s)",  "locale": "en" } ] }
    // … 29 more
  ]
}

multipaz reads that same object for the credential-level display and drops claims on the floor:

multipaz/multipaz/src/commonMain/kotlin/org/multipaz/provisioning/openid4vci/IssuerConfiguration.kt

Lines 95 to 107 in 145e9e1

	credentials[id] = CredentialMetadata(
	display = extractDisplay(
	element = config.objOrNull("credential_metadata") ?: config,
	httpClient = httpClient,
	clientPreferences = clientPreferences
	),
	format = format,
	keyBindingType = keyProofType,
	maxBatchSize = maxBatchSize
	)
	}

CredentialMetadata has nowhere to put them — it carries a credential-level Display and nothing else:

multipaz/multipaz/src/commonMain/kotlin/org/multipaz/provisioning/CredentialMetadata.kt

Lines 9 to 18 in 145e9e1

	data class CredentialMetadata(
	/** Credential name and visual representation of that credential in the wallet. */
	val display: Display,
	/** Format of this credential */
	val format: CredentialFormat,
	/** Determines how the key to which the credential is bound should be provided to the issuer */
	val keyBindingType: KeyBindingType,
	/** Maximum number of credentials that can be requested in a single request */
	val maxBatchSize: Int
	) {

Why it matters

A wallet that relies on multipaz for issuance metadata has no source for claim names other than a local DocumentTypeRepository. For any credential type not baked into the app — which is the whole point of a wallet that can be pointed at a new issuer — the user is shown raw identifiers like family_name and birth_date, in English, regardless of the locale the issuer published. The issuer sent the right names; they were parsed and discarded.

Suggested fix

Carry the per-claim display through: a claims: List<ClaimMetadata> on CredentialMetadata, where each entry holds the claim path and its display entries, populated in IssuerConfiguration from credential_metadata.claims[].

One design note from implementing this ourselves: we found it necessary to keep all published locales rather than resolving to one at parse time, so the language can be chosen when the screen is drawn rather than frozen at issuance. extractDisplay currently resolves against clientPreferences.locales during parsing (and carries a TODO about exact-match-only being too restrictive), which would freeze claim names to the locale in force at issuance time.

Related

• Unable to retrieve all credential_metadata display attributes #1784 (closed) reported the same class of loss one level up — description, background_color, background_image, text_color missing from Display — and those attributes are now on Display. This is the remaining half of that metadata gap: the credential-level display was completed, the per-claim display is still discarded.

Workaround we ship

Our compatibility layer re-reads the raw issuer metadata JSON and lifts credential_metadata.claims[].display[] out itself, keyed by doctype/vct, storing every locale alongside the document.

[mc1100]

Same defect, second field — reporting it here rather than separately because the fix is the same one.

credential_metadata.credential_reuse_policy is discarded along with claims. It appears zero times in the repository (checked against main @ 145e9e1a), and CredentialMetadata has nowhere to put it.

It is ETSI TS 119 472-3's policy statement, and the EU reference issuer publishes it for both PID configurations:

"credential_reuse_policy": {
  "id": "arf_annex_ii",
  "options": [
    { "details": ["once_only"], "batch_size": 7, "reissue_trigger_unused": 6 }
  ]
}

Why losing this one has teeth

It carries the batch size the issuer will actually honour and the threshold at which the wallet should re-issue. Without it, the only batch-related number a wallet can see through multipaz is maxBatchSize, which comes from batch_credential_issuance.batch_size — an upper limit, not the policy.

Using the limit as if it were the policy is the natural mistake, and we made it: our wallet asked for 20 credentials (the advertised maximum) against an issuer whose policy says 7. Twenty were requested, seven were certified, and the document counter read 7/20 — which looked like a partial failure and was in fact the issuer applying the policy it had published all along. The reference EUDI Android wallet reads credential_reuse_policy (via ReusePolicyMapper, selecting the first supported option) and asks for 7.

The reissue_trigger_unused / reissue_trigger_lifetime_left members are the other half: they are what tells a wallet when to top up, and there is currently no way to learn them from multipaz.

Suggested fix

Carry it through alongside the per-claim display this issue already asks for — the parse site is the same config.objOrNull("credential_metadata") in IssuerConfiguration. Selecting an option from the issuer's prioritised list could reasonably be left to the caller; what a wallet cannot do today is see that the list exists.

Wire member names, for reference (ETSI119472Part3 in eudi-lib-jvm-openid4vci-kt): options, details, batch_size, reissue_trigger_unused, reissue_trigger_lifetime_left (seconds). Note details values are punctuated inconsistently in the spec — once_only and limited_time, but rotating-batch and per-relying-party.