This document proposes extensions to OpenID Connect to enable identity assurance and verification of identity claims. It discusses representing verification details explicitly, distinguishing verified from non-verified claims, and supporting verification across different contexts. Key concepts include attaching metadata about the verification process, trust framework, and evidence to verified claims. Requests can specify desired claims and verification attributes for privacy. The proposal aims to clarify representation of verified identity data and support use across channels while preserving privacy.
4. {
"sub": "112183889",
"email": "john@doe.example",
"email_verified": true,
"given_name": "John",
"family_name": "Doe",
"birthdate": "1955-03-12",
"address": {
"country": "BE",
"locality": "Examplecity"
}
}
{
"sub": "112183889",
"email": "john@doe.example",
"email_verified": true,
"given_name": "John",
"family_name": "Doe",
"birthdate": "1955-03-12",
"address": {
"country": "BE",
"locality": "Examplecity"
}
}
Identity information
● eGovernment ● Anti Money Laundering ● Telecommunications
● Health Data ● Fraud Prevention ● Risk Mitigation
Rules?
When verified?
How verified?
Who verified?
Evidence?
5. OpenID Connect for Identity Assurance
⇢ Development in eKYC & IDA WG at the OpenID Foundation
⇢ Representation for verified claims and verification information
⇢ Enables
○ mapping between regulatory and legal contexts
○ dispute resolution
○ auditing
7. Concept 1: Explicitness
⇢ Explicit Attestation of
○ Trust Framework + Identity Assurance Level
○ Time of verification
○ Verifying party
○ Evidence used in the process
○ Verification method: how the evidence was verified
10. Concept 2: Clarity
⇢ Clear distinction between claims with and without
attestation
⇢ Can be used together with existing OpenID
Connect Claims
⇢ Separate data structure for verification data
11. {
"sub": "24400320",
"email": "janedoe@example.com",
"preferred_username": "j.doe",
"picture": "http://example.com/janedoe/me.jpg",
"verified_claims": {
"verification": {
"trust_framework": "de_aml",
"time": "2012-04-23T18:25Z",
"verification_process": "f24c6f4ec597",
"evidence": ...
},
"claims": {
"given_name": "Max",
"family_name": "Meier",
"birthdate": "1956-01-28"
}
}
}
Standard OpenID Connect Claims
Verified Claims data structure
ID Token with Standard and verified Claims
12. Concept 3: Versatility
⇢ Representation suitable for various channels
○ ID Token
○ Userinfo-Endpoint
○ Access Tokens
○ Token Introspection Responses
⇢ Support for verified data sets with different
metadata
⇢ Support for aggregated and distributed claims
13. {
"sub": "24400320",
"email": "janedoe@example.com",
"preferred_username": "j.doe",
"picture": "http://example.com/janedoe/me.jpg",
"verified_claims": [
{
"verification": {
"trust_framework": "eidas",
"identity_assurance_level`": "substantial"
},
"claims": {
"given_name": "Max",
"family_name": "Meier",
"birthdate": "1956-01-28",
}
},
{
"verification": {
"trust_framework": "de_aml"
},
"claims": {
"address": {
"locality": "Maxstadt",
"postal_code": "12344",
"country": "DE",
"street_address": "An der Sanddüne 22"
}
}
}
]
}
First set of verified Claims (eIDAS)
Second set of verified Claims (AML)
ID Token with two verified claims sets
16. Concept 4: Preservation of Privacy
⇢ Relying party can express fine-grained data
requests via “claims” parameter
⇢ Asks for individual Claims and verification data
elements
⇢ Purpose of request can be conveyed
(per transaction or individual claim)
21. OpenID for Authority
● Inspired by legal entity use cases but built to deliver “on-behalf of” in legal entity and natural
person use cases
● It is often implicit when a user is representing a company, and worse, credentials are commonly
shared when representing a natural person.
● This is an additional spec that adds the “authority” element containing:
○ “Applies_to” - contains data about the entity that the authority applies to
○ “Permission”- defining the actions that the end user is permitted to take
○ “Granted_by” - definition of how the authority was granted to the end user
● This allows various end use “on-behalf of” use cases to be more explicitly described
22. Advanced Syntax for Claims
● Extension to OpenID Connect request and responses to address advanced use cases
● omit/abort if not available: RP can control OP behavior in case of incomplete claim sets
○ Example: RP requires family_name, given_name, and birthdate for identification, but the
later is not available for a particular user
○ Privacy enhancing, important for paid services
● Lightweight expression language:
○ RP may request predicate over claim
○ Example: age verification
○ Privacy enhancing
● Response metadata
○ Provides RP with information about request
processing (e.g. why certain claims were not provided)
{
"verified_claims": {
...
"claims": {
"birthdate|years_ago|gte(21)": true
}
}
}
23. eKYC & IDA WG roadmap overview
eKYC & IDA Working Group
Final
Conformance Testing
Authority Claims
2020 2021
Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4
Implementers Draft 3
Industry Collaborations
Implementers Draft 2
Development of use case examples
Production Implementations exist
Advanced Syntax
