Skip to content

feat: add an ehic scope releasing EHIC credential claims - #20

Merged
leifj merged 1 commit into
mainfrom
feat/ehic-scope
Aug 21, 2026
Merged

leifj merged 1 commit into
mainfrom
feat/ehic-scope

Conversation

@leifj

@leifj leifj commented Aug 21, 2026

Copy link
Copy Markdown
Contributor

Problem

EHIC cannot be issued at all in the SIROS stack.

vc's apigw maps the ehic scope to its assertion (OIDC-backed) data source, and requests the credential type as the OIDC scope — Scopes: []string{session.CredentialType} in its OIDC RP callback. But ehic wasn't in scopes_supported, and no user carried EHIC data.

Change

Adds an ehic scope releasing the EHIC claim set, plus EHIC data for the three sample natural persons.

Claims are emitted under the names the EHIC credential type (urn:eudi:ehic:1) declares, because apigw uses the OIDC claims verbatim as the credential's document data (DocumentData: claims). Anything named differently simply isn't present to disclose later, and a verifier's DCQL query for it won't match.

Two details worth flagging for review:

  • EHIC data is a nested struct on User, not more flat fields. The EHIC type nests issuing_authority and authentic_source as id+name objects, whereas the profile scope releases issuing_authority as a plain string. The same claim name means different shapes in the two credential types, so they can't share one field.

  • ehic is added to the backwards-compat guard. Without that, an ehic-only request — exactly what apigw sends — would match none of profile/email/organisation, fall through to "return all claims", and overwrite the EHIC objects with the profile string form. That failure mode is covered by a test.

Test plan

  • TestClaimsForScopesEHIC — the scope releases the nested id+name objects and no profile claims
  • TestClaimsForScopesEHICOmittedWhenNil — a user without EHIC data yields no EHIC claims rather than empty ones
  • go build ./... and go test ./... pass

🤖 Generated with Claude Code

EHIC could not be issued at all: vc's apigw maps the ehic scope to its
assertion data source (OIDC-backed), and requests the credential type as the
OIDC scope - Scopes: []string{session.CredentialType} in its OIDC RP
callback - but "ehic" was not in scopes_supported and no user carried EHIC
data.

Claims are emitted under the names the EHIC credential type
(urn:eudi:ehic:1) declares, because apigw uses the OIDC claims verbatim as
the credential's document data (DocumentData: claims). Anything named
differently simply isn't present to disclose later, and a verifier's DCQL
query for it won't match.

EHIC data is a nested struct on User rather than more flat fields: the EHIC
type nests issuing_authority and authentic_source as id+name objects, while
the "profile" scope releases issuing_authority as a plain string. The same
claim name means different shapes in the two credential types, so they can't
share one field.

"ehic" is added to the backwards-compat guard as well. Without that, an
ehic-only request - exactly what apigw sends - would match none of
profile/email/organisation, fall through to "return all claims", and
overwrite the EHIC objects with the profile string form.

Tested: the ehic scope releases the nested objects and no profile claims,
and a user without ehic data yields no EHIC claims rather than empty ones.
@sonarqubecloud

Copy link
Copy Markdown

@leifj
leifj merged commit 56cf336 into main Aug 21, 2026
12 checks passed
@leifj
leifj deleted the feat/ehic-scope branch August 21, 2026 15:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant