Claim configuration

In order to support mapping of SSI credential data or NFT token metadata to standard OIDC scopes and claims, you have to define which credential types or NFTs are required and which property or trait in the credential/NFT data contains the claimed information.

If the required VP token claim or NFT token claim cannot be derived from the authorization request, one can configure default claims, that will be sent to the SSI or NFT wallet in this case.

Based on the configured claim mappings and the required claims or scopes in the authorization request from the client application, the IDP will decide which credentials or NFTs need to be requested from the user wallet.

This list of claim mappings will be reflected in the well-known openid-configuration discovery document, publishing the supported claims and scopes (scopes_supported, claims_supported).

Mapping Configuration

In general, we can configure the claim mappings in the IDP configuration file, in the claimConfig property, which contains an array of mapping objects for verifiable credentials: vc_mappings and NFT tokens: nft_mappings.

vc_mappings

Example:

{
  [...]
  "claimConfig": {
    "vc_mappings": [
      {
        "scope": [ "profile" ],
        "claim": "name",
        "credentialType": "VerifiableId",
        "valuePath": "$.credentialSubject.firstName $.credentialSubject.familyName"
      },
      {
        "scope": [ "profile" ],
        "claim": "family_name",
        "credentialType": "VerifiableId",
        "valuePath": "$.credentialSubject.familyName"
      }
      [...]
    ]
  }
  [...]
}

Each mapping object contains the following properties:

• scope: One or multiple OIDC scope(s), this claim belongs to. E.g. profile, address, email, etc.

• claim: The name of the OIDC claim. E.g. name, given_name, family_name, email, etc.

• credentialType: The type of credential from which the claim information should be read

• valuePath: A JSON path leading to the claim value in the credential data. This supports multiple JSON paths separated by blanks, to concatenate values, like shown in the example claim name in the profile scope.

nft_mappings

Example:

{
  [...]
  "claimConfig": {
    "nft_mappings": [
      {
        "scope": [ "profile" ],
        "claim": "name",
        "chain": "POLYGON",
        "smartContractAddress": "0x12345678901234567890",
        "trait": "name"
      },
      [...]
    ]
  }
  [...]
}

Each mapping object contains the following properties:

• scope: One or multiple OIDC scope(s), this claim belongs to. E.g. profile, address, email, etc.

• claim: The name of the OIDC claim. E.g. name, given_name, family_name, email, etc.

• chain: The chain on which the NFT must be held by the user

• smartContractAddress: The address of the NFT collection, which the user must hold an NFT of

• trait: Key of the NFT metadata, which will be used to fill this particular claim value

Default claims

If the authorization request from the client application contains only the scope vp_token or nft_token, but does not specify any further scopes or claims to derive the required nft or verifiable presentation from, the IDP Kit will fall back to the default claims configured here:

default_nft_token_claim

The default claim used to fulfill an NFT token request.

Example:

{
  [...]
  "claimConfig": {
    [...]
    "default_nft_token_claim": {
      "chain": "POLYGON",
      "smartContractAddress": "0x12345678901234567890"
    }
  }
  [...]
}

The default nft token claim defines the following properties:

• chain: The chain on which the NFT must be held by the user

• smartContractAddress: The address of the NFT collection, which the user must hold an NFT of

default_vp_token_claim

The default claim used to request a verifiable presentation from the SSI wallet:

Example:

{
  [...]
  "claimConfig": {
    [...]
    "default_vp_token_claim": {
      "presentation_definition": {
        "id": "1",
        "input_descriptors": [
          {
            "id": "1",
            "constraints": {
              "fields": [
                {
                  "id": "1",
                  "path": [ "$.type" ],
                  "filter": { "const":  "VerifiableId" }
                }
              ]
            }
          }
        ]
      }
    }
  }
  [...]
}

The default vp token claim contains a presentation_definition object as specified by the DIF specification: Presentation Definition.

In this example, a filter for credentials with the type VerifiableId is definied.