LogoLogo
ProductsCommunityGitHubShare Feedback
IDP Kit
IDP Kit
  • What is the IDP Kit?
    • Introduction
    • IDP Kit
      • IDP Kit | Basics
        • Overview
        • Functionality
      • Architecture
  • Getting started
    • Quick Start
    • CLI | Command Line Interface
    • REST APIs
    • Dependency (JVM)
    • Public deployments
    • Build
      • Docker
  • Demos
    • Try Login With NFT
  • Tutorials
    • Login with NFTs | Next.js
      • IDP Kit Setup
      • Client Registration
      • NFT Collection Configuration
      • Next.js
    • Login with NFTs | Keycloak
      • IDP Kit Setup
      • Client Registration
      • NFT Collection Configuration
      • Keycloak (18.0.2)
      • Keycloak (>19.0.1)
      • Frontend - Next.js
    • Login with SSI | Next.js
      • IDP Kit Setup
      • Client Registration
      • Verifiable Credential Config
      • Next.js
  • Configuration and Setup
    • IDP Kit configuration and setup
    • OIDC Manager configuration
      • Keys and signatures
      • Client registration
      • Client authentication
      • Claim configuration
    • SIOP Manager configuration
    • NFT Manager configuration
  • Concepts
    • OIDC Authentication - Recap
    • Identity provision via SSI
    • Identity provision via NFTs
      • EVM | Identity Provision
        • Sign in With Ethereum (SIWE)
      • Tezos | Identity provision via NFTs
        • Sign-In with Tezos (SIWT)
      • Near | Identity provision via NFTs
        • Sign-in with Near Protocol (SIWN)
      • Polkadot | Identity provision via NFTs
        • Sign-in with Polkadot (SIWP)
      • Flow | Identity provision via NFTs
        • Sign-in with Flow (SIWF)
      • Algorand | Identity provision via NFTs
        • Sign-in with Algorand (SIWA)
    • IAM / KeyCloak integration
  • Community
    • Discord
    • Twitter
    • Newsletter
    • GitHub Discussions
  • DEVELOPER RELATIONS
    • Contribute
    • Roadmap
    • Share Feedback
    • Contact
  • Product Editions
    • Open Source | Always Free
    • Enterprise
    • Cloud Platform
Powered by GitBook
On this page
  • Mapping Configuration
  • vc_mappings
  • nft_mappings
  • Default claims
  • default_nft_token_claim
  • default_vp_token_claim

Was this helpful?

Export as PDF
  1. Configuration and Setup
  2. OIDC Manager configuration

Claim configuration

PreviousClient authenticationNextSIOP Manager configuration

Last updated 2 years ago

Was this helpful?

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 , 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" }
                }
              ]
            }
          }
        ]
      }
    }
  }
  [...]
}

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

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

Presentation Definition
configuration file