Overview
Hopae Connect 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
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
Hopae Connect 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.Address Claim Structure
Personal attributes are returned under
/userinfo.user.*. The ID Token contains no PII. It carries only technical claims (for example: sub, acr, hopae_loa).Choosing which claims to request
You choose claims in the workflow, not per request: its Claims tab selects the claims for every connection, plus claims that only a particular connection can return. Get Connections shows each connection’savailableClaims so you know what can be requested.
One claim is special: source_id, the identifier the source uses for this person, stable for the same person on the same connection. It is opt-in (tick Source ID on the workflow’s Claims tab), not every connection provides one, and even a connection that does may not for a given verification, depending on the identity provider and the user’s status with it. When it cannot be derived it is listed in missing_claims, and its value can change for the same person when the source claim behind it changes (for example a reissued document). See Source ID.
Examples: Provider data vs. normalized /userinfo.user:
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 (request it with missing_claims=true). Claims listed there weren’t provided by the source, so handle fallbacks accordingly.Match Flows Use the Same Names
The normalization catalog above also applies to match connections:userInput keys are submitted using the normalized names (e.g. name, birthdate), and the result echoes them back unchanged in match.submitted_fields and as match.details keys. Fields with no normalized catalog entry (e.g. a provider-specific national ID lookup key) keep their provider-native name, as listed in the connection’s userInputSchema. Hopae translates to the upstream source’s native names at the provider boundary, so the provenance audit trail stays aligned with the source (e.g. fullName) while everything you submit and read back is normalized. See User Input.
Next Steps
OIDC Integration
Implement standardized attributes
OIDC UserInfo
Retrieve detailed context and evidence
Verification Process
Understanding the flow