Igrantio Credential Schema Lpid

Legal Person Identification Data (LPID) credential schema

When to use

Use this skill when you issue or ask for Legal Person Identification Data. LPID identifies an organisation, not a natural person. It is the company counterpart of the Person Identification Data (PID) credential, and it is the base identity credential of a European Business Wallet (EUBW). The schema holds two claims: the registered identifier of the organisation and its legal name.

The registry publishes this schema in all three formats:

This page describes registry version 2025.7.1, the latest version of the template.

Claim path pointer document - dc+sd-jwt

{
  "claims": [
    {
      "path": [
        "identifier"
      ],
      "mandatory": true,
      "limitDisclosure": true
    },
    {
      "path": [
        "legalName"
      ],
      "mandatory": true,
      "limitDisclosure": true
    }
  ]
}

Claim path pointer document - jwt_vc_json

{
  "claims": [
    {
      "path": [
        "credentialSubject",
        "identifier"
      ],
      "mandatory": true
    },
    {
      "path": [
        "credentialSubject",
        "legalName"
      ],
      "mandatory": true
    }
  ]
}

Claim path pointer document - mso_mdoc

{
  "claims": [
    {
      "path": ["org.iso.18013.5.1", "identifier"],
      "mandatory": true,
      "limitDisclosure": true
    },
    {
      "path": ["org.iso.18013.5.1", "legalName"],
      "mandatory": true,
      "limitDisclosure": true
    }
  ]
}

The metadata namespace and the namespace in the claim paths are not the same value. The claim paths use org.iso.18013.5.1. Send the paths as the schema document gives them, because the issuer builds the mdoc from the paths.

How to read the fields

Each item of the claims array is one claim path pointer.

• path is an array that selects one claim. Each element is a string for an object key, an integer for an array index, or null for every element of an array. The three formats point at the same two claims with three different prefixes:
  • dc+sd-jwt uses the bare claim name, so each path holds one element.
  • jwt_vc_json starts every path with credentialSubject.
  • mso_mdoc starts every path with the mDoc namespace org.iso.18013.5.1. Every path of the configuration must start with the same namespace element.
• mandatory says if the claim must hold a value when you issue. The issuer reads a missing mandatory as true. Both claims are mandatory in all three formats, so an issue request must fill both.
• limitDisclosure says if the holder can disclose the claim on its own. The dc+sd-jwt and mso_mdoc documents set it to true. The jwt_vc_json document leaves it out, because jwt_vc_json has no selective disclosure.

identifier holds the registered identifier of the organisation, for example the company registration number. legalName holds the registered name.

Use with the iGrant.io API

Create a credential definition with:

POST /v2/config/digital-wallet/openid/sdjwt/credential-definition

Put one entry in credentialDefinitions[] for each format that you publish, and copy the claims array of the matching schema document into that entry.

• Set version to version_01 at the top level of the request.
• For dc+sd-jwt: set vct to LegalPersonIdentificationData, put the array in claims.claims, and set validationPath to $.
• For jwt_vc_json: set type to an array that holds LegalPersonIdentificationData, put the array in credentialDefinition.claims, and set validationPath to $.vc.
• For mso_mdoc: set doctype to org.iso.18013.5.1.lpid, put the array in claims.claims, and set validationPath to $.

{
  "label": "Issue Legal Person Identification Data",
  "version": "version_01",
  "credentialDefinitions": [
    {
      "credentialFormat": "dc+sd-jwt",
      "vct": "LegalPersonIdentificationData",
      "validationPath": "$",
      "supportRevocation": true,
      "revocationMethod": "status_list",
      "claims": {
        "claims": [
          { "path": ["identifier"], "mandatory": true, "limitDisclosure": true },
          { "path": ["legalName"], "mandatory": true, "limitDisclosure": true }
        ]
      }
    },
    {
      "credentialFormat": "mso_mdoc",
      "doctype": "org.iso.18013.5.1.lpid",
      "validationPath": "$",
      "claims": {
        "claims": [
          {
            "path": ["org.iso.18013.5.1", "identifier"],
            "mandatory": true,
            "limitDisclosure": true
          },
          {
            "path": ["org.iso.18013.5.1", "legalName"],
            "mandatory": true,
            "limitDisclosure": true
          }
        ]
      }
    }
  ]
}

When you issue, the top key of claims for the mso_mdoc entry is the namespace org.iso.18013.5.1.

Read igrantio-api-issuer for the full operation reference: every request field, the display options, revocation, and the issue operation that fills these claims. Read igrantio-api-verifier for the DCQL query that asks for the legal name.

Source is the registry

This skill mirrors the claim path pointer template in the iGrant.io verifiable data registry. If this skill and the registry file disagree, the registry wins. Fetch the source before you rely on a claim path:

• Template: https://github.com/decentralised-dataexchange/verifiable-data-registry/tree/main/credentialSchemas/claimPathPointer/lpid
• Raw SD-JWT schema: https://raw.githubusercontent.com/decentralised-dataexchange/verifiable-data-registry/main/credentialSchemas/claimPathPointer/lpid/2025.7.1/dc%2Bsd-jwt.schema.json
• Raw JWT schema: https://raw.githubusercontent.com/decentralised-dataexchange/verifiable-data-registry/main/credentialSchemas/claimPathPointer/lpid/2025.7.1/jwt_vc_json.schema.json
• Raw mdoc schema: https://raw.githubusercontent.com/decentralised-dataexchange/verifiable-data-registry/main/credentialSchemas/claimPathPointer/lpid/2025.7.1/mso_mdoc.schema.json

Each schema file has a .schema.metadata.json file beside it. A newer version directory can appear in the registry. Check the directory listing for a version above 2025.7.1 and use the newest one.