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.

1. OpenID Connect 4
Identity Assurance
Torsten Lodderstedt, yes.com

2. What is this about?

3. Identity information
{
"sub": "112183889",
"email": "john@doe.example",
"email_verified": true,
"given_name": "John",
"family_name": "Doe",
"birthdate": "1955-03-12",
"address": {
"country": "BE",
"locality": "Examplecity"
}
}
Assumptions
● Verification rules
(Laws, regulations and contracts)
● Verification status
● Verification methods
→ Implicit Trust
Relying Party
Identity Provider

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

6. Main Concepts

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

8. {
"verified_claims":{
"verification":{
"trust_framework":"de_aml",
"time":"2012-04-23T18:25Z",
"verification_process":"f24c6f-6d3f-4ec5-973e-b0d8506f3bc7",
"evidence":[
{
"type":"id_document",
"method":"pipp",
"verifier":{
"organization":"Deutsche Post",
"txn":"1aa05779-0775-470f-a5c4-9f1f5e56cf06"
},
"time":"2012-04-22T11:30Z",
"document":{
"type":"idcard",
"issuer":{
"name":"Stadt Augsburg",
"country":"DE"
},
"number":"53554554",
"date_of_issuance":"2010-03-23",
"date_of_expiry":"2020-03-22"
}
}
]
},
"claims":{
"given_name":"Max",
"family_name":"Meier",
"birthdate":"1956-01-28",
"place_of_birth":{
"country":"DE",
"locality":"Musterstadt"
}
}
}
}
Example
Verification Data
End-User Claims
verified_claims
Container

9. Verification Details
"verification": {
"trust_framework": "de_aml",
"time": "2012-04-23T18:25Z",
"verification_process": "f24c6f-6d3f-4ec5-973e-b0d8506f3bc7",
"evidence": [
{
"type": "id_document",
"method": "pipp",
"verifier": {
"organization": "Deutsche Post",
"txn": "1aa05779-0775-470f-a5c4-9f1f5e56cf06"
},
"time": "2012-04-22T11:30Z",
"document": {
"type": "idcard",
"issuer": {
"name": "Stadt Augsburg",
"country": "DE"
},
"number": "53554554",
"date_of_issuance": "2010-03-23",
"date_of_expiry": "2020-03-22"
}
}
]
},
German Money Laundering Act
Physical In-Person Proofing
Proofing via ID Card
External verifier on behalf of the IDP

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

14. {
"iss": "https://self-issued.me",
"sub": "248289761001",
"preferred_username": "superman445",
"_claim_names": {
"verified_claims": [
"src1",
"src2"
]
},
"_claim_sources": {
"src1": {
"JWT": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwcz
ovL3NlcnZlci5vdGhlcm9wLmNvbSIsInN1YiI6ImU4MTQ4NjAzLTg5MzQtNDI0N
S04MjViLWMxMDhiOGI2Yjk0NSIsInZlcmlmaWVkX2NsYWltcyI6eyJ2ZXJpZmlj
YXRpb24iOnsidHJ1c3RfZnJhbWV3b3JrIjoiaWFsX2V4YW1wbGVfZ29sZCJ9LCJ
jbGFpbXMiOnsiZ2l2ZW5fbmFtZSI6Ik1heCIsImZhbWlseV9uYW1lIjoiTWVpZX
IiLCJiaXJ0aGRhdGUiOiIxOTU2LTAxLTI4In19fQ.FArlPUtUVn95HCExePlWJQ
6ctVfVpQyeSbe3xkH9MH1QJjnk5GVbBW0qe1b7R3lE-8iVv__0mhRTUI5lcFhLj
oGjDS8zgWSarVsEEjwBK7WD3r9cEw6ZAhfEkhHL9eqAaED2rhhDbHD5dZWXkJCu
XIcn65g6rryiBanxlXK0ZmcK4fD9HV9MFduk0LRG_p4yocMaFvVkqawat5NV9QQ
3ij7UBr3G7A4FojcKEkoJKScdGoozir8m5XD83Sn45_79nCcgWSnCX2QTukL8Ny
wIItu_K48cjHiAGXXSzydDm_ccGCe0sY-Ai2-iFFuQo2PtfuK2SqPPmAZJxEFrF
oLY4g"
},
"src2": {
"endpoint": "https://op.mymno.com/claim_source",
"access_token": "ksj3n283dkeafb76cdef"
}
}
}
Multiple verified Claims sets
Aggregated Claims
Distributed Claims
Aggregated & Distributed Claims
{
"iss": "https://otherop.com",
"sub": "e814864108b8b6b45...",
"verified_claims": {
"verification": {
"trust_framework": "example"
},
"claims": {
"given_name": "Max",
"family_name": "Meier",
"birthdate": "1956-01-28"
}
}
}

15. Identity information
Requesting Identity Information
Identity information
Request

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)

17. {
"userinfo": {
"verified_claims": {
"verification": {
"trust_framework": null,
},
"claims": {
"given_name": null,
"family_name": null,
"birthdate": null
}
}
}
}
trust framework is mandatory
Requested Claims
Simple Request
delivery via userinfo

18. {
"userinfo": {
"verified_claims": {
"verification": {
"trust_framework": {
"value": "de_aml"
},
"time": null,
"evidence": [
{
"type": {
"value": "id_document"
},
"method": null,
"document": {
"type": null
}
}
]
},
"claims": {
"given_name": null,
"family_name": null,
"birthdate": null
}
}
}
}
Requires trust framework “de_aml”
Requires evidence type ID document
Requested Claims
Advanced Request
Requests “time”
Requests verification method
and document type

19. International Standard
⇢ Identifiers for…
⇢ Extensible
⇢ Contributions welcome!
Trust Frameworks
eIDAS & NIST 800-63A
Japanese & German AML
...
Identity Documents
ID Card & Passport
Driver’s License
...
Verification Methods
Physical In-Person Proofing
Supervised remote In-Person Proofing
...
Full list: https://bitbucket.org/openid/ekyc-ida/wiki/identifiers

20. What else?

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

24. Thank you!
Dr. Torsten Lodderstedt, yes.com
Twitter: @tlodderstedt
https://yes.com