Updated: Sep 27, 2022
In this article, we try to understand critical concepts for Identity Assurance used by OpenID Connect. The idea here is to provide an overview of the standards. Please note that this is an evolving standard, and we expect more changes in the specification soon.
Let’s try to understand the key concepts for Identity Assurance.
Claim: is a technical term that refers to a user attribute such as a given name, birthday, address, etc.
Verified: claim’s authenticity has been confirmed with Evidence such as a passport, driver’s license, and so on.
What is the need?
Beyond authentication and authorization, there is a solid need to verify the user’s identity in specific industry verticals like banking & finance, insurance, telecommunication, etc.
Essential requirements are:
Verify legal name & legal age enforceable by law
Mandatory data to fulfill contract requirements like address, nationality or residency, credit score, etc.
Anti-Money Laundering checks
There are two parts of identity assurance,
Identity Assurance covers
Identity Assurance is typically a governance framework verifying user claims like name, address, date of birth, etc.
What documents are acceptable for verification(referred to as Evidence)?
What claims are to be verified, and how to verify them (referred to as Method)?
Level of assurance required for a particular requirement?
These governing frameworks are referred to as Trust Framework
2. Identity Assurance exchange covers
What information is to be communicated?
How do we exchange such information?
OpenID Connect for Identity Assurance 1.0 (OIDC4IDA or IDA) is a technical specification developed by the eKYC-IDA Working Group. It uses OAuth 2.0 and OpenID Connect (OIDC) as its base and defines a JSON structure that conveys verified claims of a natural person (https://bitbucket.org/openid/ekyc-ida/src/master/schema/verified_claims.json)
The verified_claims JSON object contains verification and claims as top-level properties.
The verification JSON object describes information about the verification process, such as trust framework, pieces of evidence, methods, who, and when.
The claims JSON object contains pairs of names and values of verified claims.
Verified Claims Request
Client applications use the claims request parameter of an authorization request to request required data. The specification supports claims in ID Token and the UserInfo endpoint. From a privacy perspective, it is better not to get data in ID Token as it is visible on the front channel.
Verified Claims Response
The specification requires that servers not return data that is not explicitly requested. This policy is called data minimization. If requested claims are unavailable, the protocol returns empty strings and will not throw the error.
As I mentioned, it is evolving standard and depends on currently growing trust frameworks and their requirements. Some new specifications for SSI (Self-Sovereign Identity) support the OpenID connect interface for getting user claims from the digital identity wallets. There are many use cases around verified claims in finance, insurance, travel, etc., so this is a vital specification for the industry.
We will discuss verifiable credentials and their growing importance and parallel standards, which can impact the future of identity in many use cases in future articles.