Skip to main content

​
Overview

hConnect solves the fragmentation problem of identity providers by standardizing user attributes across all eID providers. No matter which provider your users choose, you receive consistent, predictable data formats.

​
The Problem: Data Chaos

Each identity provider uses different attribute names for the same user information, creating significant integration complexity: Example: Attribute Naming Chaos
InformationProvider AProvider BProvider C
First NamefirstNamegiven_namefirstname
Last NamelastNamefamily_namesurname
Birth DatedateOfBirthbirthdatedob
National IDpersonalNumberssnnationalNumber
Without standardization, you would need to:
  • Write custom mapping logic for each provider
  • Maintain provider-specific code branches
  • Handle different date formats and data types
  • Update your code when providers change their schemas

​
Normalized Attributes

hConnect maps all provider variations into a attribute set based on OpenID Connect Standard Claims. These are standard OpenID Connect claims representing the user’s identity.
AttributesTypeRequiredNotes/Example
namestringNoFull name
given_namestringNo
family_namestringNo
middle_namestringNo
nicknamestringNo
preferred_usernamestringNo
profilestringNoURL
picturestringNoBase64-encoded image data
genderstringNofemale, male, other
birthdatestringNoYYYY-MM-DD
localestringNoBCP 47 (en-US)
emailstringNouser@example.com
email_verifiedbooleanNotrue/false
phone_numberstringNoE.164 (+1415555…)
phone_number_verifiedbooleanNotrue/false
addressobjectNoSee Address structure below
nationalitystringNoISO 3166-1 alpha-2

​
Address Claim Structure

AttributesTypeNotes/Format
street_addressstringStreet/house/PO Box
localitystringCity
regionstringState/Province/Region
postal_codestringZIP/Postal code
countrystringISO 3166-1 alpha-2
Personal attributes are returned under /userinfo.user.*. The ID Token contains no PII; it carries only technical claims (for example: sub, acr, hopae_loa).
Examples: Provider data vs. normalized /userinfo.user: 
{
  "personalNumber": "198507124567",
  "givenName": "Anders",
  "surname": "Eriksson",
  "name": "Anders Eriksson"
}

​
Data Availability

Not all attributes are available from all providers. The availability depends on each provider’s capabilities and user consent.
If a claim is absent, check missing_claims in /userinfo. Claims listed there weren’t provided by the source — handle fallbacks accordingly.

​
Next Steps

OIDC Integration

Implement standardized attributes

OIDC UserInfo

Retrieve detailed context and evidence

Provider Reference

Available providers and coverage

Verification Process

Understanding the flow