Summary
In rb-iban-ov, the provider's unique identifier is named inconsistently. The data model, the mandatory-attributes table, the JSON Schema and the sample all use account_provider.euid — but both example payloads in the README (§3.2.3) put it under account_provider.bank_identifier.
Because the schema sets additionalProperties: false on account_provider and lists euid as required, a payload copied from the README example fails schema validation, while a schema-valid payload contradicts the README example. Since an issuer typically follows the on-the-wire example, this directly affects CS-01 conformance.
Verified at HEAD 14a89e4.
The conflict — one field, two names
| Location |
Field name for the provider identifier |
| README §2.1 data model tree |
euid |
| README §2.2 mandatory attributes table |
euid |
| README §3.2.1 encoding table — Data Identifier column |
bank_identifier |
| README §3.2.1 encoding table — Attribute identifier column |
account_provider.euid |
| README §3.2.3 example payload (legal person) |
"bank_identifier": "DE-HRB-654321" |
| README §3.2.3 example payload (natural person) |
"bank_identifier": "DE-HRB-654321" |
data-schemas/sd-jwt/iban-ov-sd-jwt.json |
euid (required; additionalProperties: false) |
data-schemas/sd-jwt/sample-data/iban-ov-sd-jwt-sample.json |
"euid": "DE-HRB-654321" |
The §3.2.1 encoding row is itself split: it labels the field bank_identifier but maps it to the path account_provider.euid.
Why it breaks
With iban-ov-sd-jwt.json requiring euid and forbidding extra properties on account_provider:
- A payload built from the README §3.2.3 example (
bank_identifier) → fails validation: missing required euid, plus an unexpected bank_identifier under additionalProperties: false.
- A payload built from the schema/sample (
euid) → valid, but no longer matches the README example an implementer would copy.
This is the same class of defect as #112 (the vct inconsistency): the effective machine constraint (schema + sample) and the human-readable prose (README examples) disagree, so an issuer cannot tell which value to put on the wire.
Ask
Confirm the canonical field is account_provider.euid — consistent with the data model (§2.1), the mandatory table (§2.2), the schema and the sample — and align the README §3.2.3 examples (both legal- and natural-person) accordingly, replacing bank_identifier with euid. Also fix the §3.2.1 Data Identifier label to euid so the encoding table is internally consistent.
If bank_identifier was in fact the intended wire name, then the schema and sample need updating instead — but that would break the alignment with the euid used elsewhere in the catalogue for register identifiers.
Related: #112 (same schema-vs-prose divergence in the same rulebook). cc @flo0x
Summary
In
rb-iban-ov, the provider's unique identifier is named inconsistently. The data model, the mandatory-attributes table, the JSON Schema and the sample all useaccount_provider.euid— but both example payloads in the README (§3.2.3) put it underaccount_provider.bank_identifier.Because the schema sets
additionalProperties: falseonaccount_providerand listseuidas required, a payload copied from the README example fails schema validation, while a schema-valid payload contradicts the README example. Since an issuer typically follows the on-the-wire example, this directly affects CS-01 conformance.Verified at HEAD
14a89e4.The conflict — one field, two names
euideuidbank_identifieraccount_provider.euid"bank_identifier": "DE-HRB-654321""bank_identifier": "DE-HRB-654321"data-schemas/sd-jwt/iban-ov-sd-jwt.jsoneuid(required;additionalProperties: false)data-schemas/sd-jwt/sample-data/iban-ov-sd-jwt-sample.json"euid": "DE-HRB-654321"The §3.2.1 encoding row is itself split: it labels the field
bank_identifierbut maps it to the pathaccount_provider.euid.Why it breaks
With
iban-ov-sd-jwt.jsonrequiringeuidand forbidding extra properties onaccount_provider:bank_identifier) → fails validation: missing requiredeuid, plus an unexpectedbank_identifierunderadditionalProperties: false.euid) → valid, but no longer matches the README example an implementer would copy.This is the same class of defect as #112 (the
vctinconsistency): the effective machine constraint (schema + sample) and the human-readable prose (README examples) disagree, so an issuer cannot tell which value to put on the wire.Ask
Confirm the canonical field is
account_provider.euid— consistent with the data model (§2.1), the mandatory table (§2.2), the schema and the sample — and align the README §3.2.3 examples (both legal- and natural-person) accordingly, replacingbank_identifierwitheuid. Also fix the §3.2.1 Data Identifier label toeuidso the encoding table is internally consistent.If
bank_identifierwas in fact the intended wire name, then the schema and sample need updating instead — but that would break the alignment with theeuidused elsewhere in the catalogue for register identifiers.Related: #112 (same schema-vs-prose divergence in the same rulebook). cc @flo0x