Polkadot | Identity provision via NFTs

This section will explain the principles of how OIDC authentication requests are translated into NFT requests and the options available to craft such requests.

The IDP Kit transforms the ownership of NFT on Polkadot into an identity access management solution. The implementation is based on three main aspects: OIDC, SIWP, NFT, and their metadata.

Any client application can use the IDP Kit to grant access to a service via the ownership of an NFT on the Polkadot Blockchain. The IDK Kit extends the verification of the NFT ownership by applying policies to the NFT metadata via an open policy agent(OPA).

How it works

To understand how identity provision via NFTs can be leveraged in an OIDC authentication flow, you may first want to recap on the basic principles of OIDC authentication.

OIDC via NFTs

The whole verification process has seven main steps:

  1. The client application redirects the user to the IDP Kit. It is a verification request based on the OIDC standard.

  2. The IDP Kit processes the verification request. If it is an NFT Polkadot verification, the IDP Kit redirects the user to his user interface.

  3. Then, the user must connect to his wallet. He shares his address with the IDP Kit and signs a message based on the SIWP process.

  4. The SIWP process continues within the IDP Kit by verifying the user address and the message signature.

  5. After that, the IDP Kit will verify that the user has an NFT in a specified collection within the Polkadot Blockchain. The NFT collection information is defined in the IDP Kit configuration file.

  6. If the NFT metadata policy verification is activated, The IDP Kit will load the NFT metadata and run an OPA policy with the NFT metadata. The OPA policy is specified in the configuration file.

  7. In the last step, the IDP Kit redirects the user to the client application with a response of the whole verification with extra information like the account address. This is based on the OIDC standard.

The authorization flow visualized

  • OpenID Connect(OIDC) is used as the protocol between any client application and the IDP Kit. It is used by the client application to make an NFT ownership verification request. The IDP Kit will well interpret the request. It is also used within the verification response by the IDP Kit to the client application.

  • SIWP is used to verify that the user controls and owns the private key of a Polkadot account.

  • We can apply policies to the NFT metadata based on the Open policy agent(OPA).

Claiming nft_token

In this scenario, the client application requests the raw NFT data, without mapping to standard OIDC claims, by specifying the custom nft_token claim or defining the nft_token scope in the authorization request.

nft_token Scope

By specifying the nft_token scope in the authorization request, the client application requests the validation of the user being a holder of an NFT in the required NFT collection and the user info to be included in the response. The IDP Kit will determine the NFT request, which is sent to the NFT wallet, by the following sources in this order:

  1. nft_token claim, specified by the client application as a custom claim object in the authorization request

  2. Derived from nft_mappings defined in the IDP Kit claim configuration, based on the scopes and claims requested in the authorization request

  3. NFT token claim, configured in thedefault_nft_token_claim in the IDP Kit claim configuration

nft_token Claim

The nft_token claim should be constructed as follows:

Authorization POST request:

When making the authorization post request, the client can specify a claim field in the body, with a value describing the NFT collection. The format will be as follows:

"claim": {
  "nft_token": {
    // blockain identifier
    "chain":"OPAL",
    // the smart contract representing the NFT collection
    "smartContractAddress":"5GTmz6Vc7tXsbiD6ujxyt8Yf17FnygJLcrBqvduU3c8NwmHP"
  }
}

Authorization GET request:

When making the authorization get request, the client can specify a claim field, as shown in the example above, in a JSON object. This object will then be sent URL encoded via the query parameters.

Standard OIDC scopes, claims and claim mapping

In this scenario, the client application simply makes a standard OIDC authorization request, like any other OIDC compliant identity provider would expect it. E.g. the application could request the profile scope, to receive name, given name, family name, gender, date of birth, etc. of the user from the IDP Kit.

The IDP Kit maps the required claims to suitable traits in the NFT metadata that contain the requested information, by getting access to the NFT through the shared address of the user. The gathering of the user address will be handled by a separate wallet connect page (web application), without the client taking any notice.

Once the IDP Kit has received the address of the user from the wallet connect page, got the information from the NFTs metadata and verified all of it. The IDP Kit translates the received data into the standard user info claims requested by the application and provides it on the standard user info endpoint.

To use this flow, the client application needs no additional knowledge about the underlying protocol. In most cases, a simple configuration change would suffice to make an application connect to the IDP Kit and accept NFT data for user authentication, given that OIDC is already used as an authentication layer.

Last updated