Optional components

These components extend the basic issuance workflow with additional capabilities. Add them only when your assurance or data requirements call for them.

Optional components

These components extend the basic issuance workflow with additional capabilities.

Authentication provider

An authentication provider is your existing OIDC-compliant identity provider (e.g., Auth0, Entra ID, Okta). It authenticates the holder during the Authorization Code flow.

Requirements:

• Must support OIDC Discovery (.well-known/openid-configuration).
• Must support the authorization code grant.
• Must support the state parameter.
• One authentication provider per MATTR VII tenant.

How it fits in the workflow:

1. Holder initiates credential claim.
2. MATTR VII redirects to your identity provider.
3. Holder authenticates and consents.
4. ID token claims become available for credential mapping.

Claims source

A claims source is an external HTTPS endpoint that MATTR VII calls during issuance to fetch additional claim data. This is useful when credential data lives in systems separate from your identity provider.

Common use cases:

• Government databases (license records, registry data).
• HR systems (employee attributes, role assignments).
• CRM or customer databases (membership tiers, entitlements).

How it fits in the workflow:

1. Holder authenticates (Authorization Code) or presents offer (Pre-authorized Code).
2. MATTR VII calls your claims source endpoint with configured parameters.
3. Your endpoint returns JSON claim data.
4. Claims are mapped into the credential via the credential configuration.

Integration requirements:

• HTTPS endpoint reachable from MATTR VII (IPv4).
• Must respond within 3 seconds.
• Supports API key or OAuth client credentials for authorization.
• Must return claims as a flat or nested JSON object.

Interaction hooks

An interaction hook adds a custom step between authentication and credential issuance in the Authorization Code flow. This lets you inject additional verification, consent collection, or data gathering.

Common use cases:

• Biometric or liveness verification.
• Additional consent or terms acceptance.
• Document upload or manual review steps.
• Custom data collection forms.

How it fits in the workflow:

1. Holder authenticates via the authentication provider.
2. MATTR VII redirects to your interaction hook URL with a signed session token.
3. Your component performs its logic (verification, consent, data collection).
4. Your component redirects back to MATTR VII with a signed response JWT containing any claims.
5. Returned claims become available for credential mapping.

Next steps

Next, manage issuer keys and certificates so your credentials are signed with keys your organization controls.