#Data & Identity Sourcing

Data & Identity Sourcing describes how the Community Stack Issuer obtains the attributes that go into a credential – for example name, date of birth, identifiers, roles, or any other claims about the subject.

The Community Stack gives you flexibility in where subject data lives and when it is fetched, allowing you to plug into existing systems (CRM, registries, IdPs, etc.) and design flows that fit your business, security, and UX requirements.

At a high level, this capability answers one question:

#What's included

The Community Stack supports three complementary ways of sourcing data for credentials. You can use them individually or combine them in a single flow.

#1. Use your own backend as the source of truth (before offer creation)

Your backend collects all required subject attributes up front and passes them to the Community Stack Issuer API when creating a credential offer.

This means:

• You stay in control of where identity data lives (databases, registries, etc.).
• The Issuer API receives a complete, ready-to-sign data structure and focuses on protocol handling and signing.
• Simple, straightforward integration for most use cases.

#2. Enrich credentials via data functions & webhooks (after offer, before signing)

You can mark specific credential attributes as "to be filled later" and let the Issuer call data functions before signing – including webhooks into your systems. Returned values are mapped into the credential right before issuance.

This means:

• Fetch dynamic or time-sensitive data at the last possible moment (e.g. timestamps, status flags, IDs, expiration dates).
• Call external APIs via webhooks for custom logic (e.g. fraud checks, entitlement checks, policy decisions) and use the result directly in the credential.
• Combine static attributes (provided up front) with dynamic attributes (via data functions) in a single issuance flow.

#3. Fetch identity data via authorization servers (OID4VCI authorization code flow)

When using the OID4VCI authorization code flow, the user is required to authenticate with an external Authorization Server / Identity Provider (IdP) before claiming a credential. After successful authentication, the Issuer API can use the resulting tokens to fetch user claims and map them into credential attributes.

This means:

• Use your existing identity infrastructure (e.g. Keycloak, Azure AD, custom OIDC IdP) as the trusted identity source.
• Ensure that attributes are tied to a fresh, interactive authentication event (step-up, MFA, etc.).
• Align with established IAM policies (scopes, consents, attribute release policies) while issuing verifiable credentials.

#FAQs

• Can I mix different data sources in a single credential issuance flow? — Yes. A single issuance can combine attributes that come from your backend, attributes returned via webhooks/data functions, and (coming soon) attributes obtained from an Authorization Server after user authentication.
• Do I need an Identity Provider to use Data & Identity Sourcing? — No. You can issue credentials entirely based on data from your backend or via webhooks. Authorization code flow with IdP integration for dynamic claims fetching is coming soon to the Community Stack.
• Can I keep sensitive attributes out of the credential while still using them in decisions? — Yes. You can use data functions and webhooks to call external systems that perform risk or eligibility checks. Only the decision (e.g. "eligible = true") has to be written into the credential; sensitive raw data can remain in your own systems.
• Can I start simple and evolve my data sourcing strategy later? — Yes. Many deployments start with a simple backend-only model and gradually introduce data functions and webhooks as requirements become more sophisticated – without changing the underlying credential formats or wallet integration.

#Get Started

• Issue a credential using pre-defined data – Step-by-step guide showing how to pass complete subject attributes from your backend when creating a credential offer (approach 1).
• Use data functions to enrich credentials dynamically – Learn how to mark attributes for late binding and use webhooks or built-in functions to fetch data right before signing (approach 2).