Finding from building the e2e golden flow (#205): the production email attribute type pbdf.sidn-pbdf.email.email is hardcoded in (at least) three layers:
postguard-js src/recipients/builders.ts — every recipient policy starts from the pbdf email attribute; there is no way to build a recipient for another attribute typecryptify src/main.rs (~line 828) — finalize rejects any upload whose sender identity lacks exactly pbdf.sidn-pbdf.email.email ("no email attribute")pg-pkg src/middleware/auth.rs (~lines 277-299) — the API-key signing identity is built with hardcoded pbdf attribute types
Why this matters:
- Testability. No test environment can issue pbdf credentials (the issuer private keys are production secrets). The e2e harness therefore cannot drive the real
@e4a/pg-js decrypt path and had to re-implement the client flow against test-scheme attributes, with API-key signing as a workaround for cryptify's sender check. Un-hardcoding this unblocks testing the real SDKs end to end (see Phase 2).
- Environment parity. Staging/test and production could run identical code paths, differing only in configuration.
- Scheme evolution. Any future change of the email attribute (scheme rename, EUDI migration) currently requires coordinated code changes in 3+ repos — exactly the "fix one thing, three others break" pattern this EPIC exists to kill.
Suggestion. Make the email attribute type a configuration value: an option in pg-js (PostGuard({emailAttribute?: ...}) or a generic recipient builder), a config key in cryptify, and a config/env value in the PKG. Default everywhere stays pbdf.sidn-pbdf.email.email.
Finding from building the e2e golden flow (#205): the production email attribute type
pbdf.sidn-pbdf.email.emailis hardcoded in (at least) three layers:postguard-jssrc/recipients/builders.ts— every recipient policy starts from the pbdf email attribute; there is no way to build a recipient for another attribute typecryptifysrc/main.rs(~line 828) — finalize rejects any upload whose sender identity lacks exactlypbdf.sidn-pbdf.email.email("no email attribute")pg-pkgsrc/middleware/auth.rs(~lines 277-299) — the API-key signing identity is built with hardcoded pbdf attribute typesWhy this matters:
@e4a/pg-jsdecrypt path and had to re-implement the client flow against test-scheme attributes, with API-key signing as a workaround for cryptify's sender check. Un-hardcoding this unblocks testing the real SDKs end to end (see Phase 2).Suggestion. Make the email attribute type a configuration value: an option in pg-js (
PostGuard({emailAttribute?: ...})or a generic recipient builder), a config key in cryptify, and a config/env value in the PKG. Default everywhere stayspbdf.sidn-pbdf.email.email.