# Authorized attributes On this page you'll find a collection of so-called claim paths, which are defined within a number of verifiable credential types (or doctypes in mdoc) we support. These claim paths are used to indicate what values you're interested in. They are used within the `authorizedAttributes` object in `reader_auth.json` documents. ## How authorized attributes are specified As mentioned, in the `reader_auth.json` document, you have an object which indicates what attributes you want to verify, called `authorizedAttributes`. In the `scripts/devenv` subdirectory of our git repository, you'll find various `*_reader_auth.json` example documents which all include an `authorizedAttributes` object. Let's take the (quite extensive) one from our "XYZ Bank" as an example: ```json "authorizedAttributes": { "urn:eudi:pid:nl:1": [ ["urn:eudi:pid:nl:1", "given_name"], ["urn:eudi:pid:nl:1", "family_name"], ["urn:eudi:pid:nl:1", "birthdate"], ["urn:eudi:pid:nl:1", "bsn"], ["given_name"], ["family_name"], ["birthdate"], ["bsn"] ], "urn:eudi:pid:1": [ ["given_name"], ["family_name"], ["birthdate"] ], "urn:eudi:pid-address:nl:1": [ ["urn:eudi:pid-address:nl:1.address", "street_address"], ["urn:eudi:pid-address:nl:1.address", "house_number"], ["urn:eudi:pid-address:nl:1.address", "postal_code"], ["address", "street_address"], ["address", "house_number"], ["address", "postal_code"] ], "urn:eudi:pid-address:1": [ ["address", "street_address"], ["address", "house_number"], ["address", "postal_code"] ] } ``` The object contains named array values; the name represents an attestation type (a _doctype_ in mdoc parlance, or a _Verifiable Credential Type_/VCT in SD-JWT speak), with a version number appended (i.e., the `1`'s after the name). In the above example: `urn:eudi:pid:nl:1`, `urn:eudi:pid:1"`, `urn:eudi:pid-address:nl:1`, and `urn:eudi:pid-address:1` are attestation type names with an appended version `1`. These attestation types are (in our implementation) defined in JSON definition documents (for example, see `scripts/devenv/eudi:*.json` in our git repository). The tables below, which show you what each attestation type can contain, are generated from those documents. ### Support for both SD-JWT- and mdoc-style authorized attributes The array contains one or more arrays with so-called "claim paths". In the example above, you'll find that some values seem a bit redundant, like: ```json [ ["urn:eudi:pid-address:nl:1.address", "street_address"], ["address", "street_address"] ] ``` In this case, the first (somewhat wordy) specification is an mdoc style path specification, and the second shorter one is an SD-JWT claim path (which in the tables below is shown as `address.street_address`). Specifying this in both forms allows the verifier (or issuer doing disclosure-based-issuance) to request ttributes from attestations in both mdoc and SD-JWT format. ### A note about extended VCTs In the VCT definition documents (in our git repository, the JSON documents that define our VCT/doctypes are `scripts/devenv/eudi:*.json`) there is an optional `extends` keyword that can indicate a parent VCT, allowing a VCT to be "extended". For example, `urn:eudi:pid:nl:1` extends `urn:eudi:pid:1` with `bsn` and `recovery_code`, in addition to Dutch language labels and descriptions for all claim paths. In `urn:eudi:pid:nl:1` you'll see an `extends` element which points to `urn:eudi:pid:1`. ## Overview of supported authorized attributes Below you'll find a few tables which show which attributes we support, in some cases in both English and Dutch form.
These tables are generated
The below tables are generated using our `authorized-attributes-tables.sh` script, which parses our `scripts/devenv/eudi:*.json` documents. If you suspect the claim path attributes you're looking at might be out-of-date, you can invoke `authorized-attributes-tables.sh` and make sure you're looking at the latest we support.
Do note that, while we use the aforementioned JSON definition documents in our locally running `pid_issuer`, it is not guaranteed that a `pid_issuer` running in one of our live environments uses these exact-same JSON definition documents. When you work with one of our live environments, and thus followed our [onboarding][1] procedure, you can contact our operations team to obtain the necessary information.