René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Support for additional X.509 JWT headers","articleBody":"## Summary\n\nThe `JWTHeader` class (`lib/one-core/src/proto/jwt/model.rs`) currently supports the X.509 certificate chain header `x5c` ([RFC7515 §4.1.6](https://www.rfc-editor.org/rfc/rfc7515.html#section-4.1.6)), but not other optional X.509 headers:\n\n - `x5u` (RFC7515 §4.1.5)\n - `x5t` (RFC7515 §4.1.7)\n - `x5t#S256` (RFC7515 §4.1.8)\n\nWhile these headers are optional in the RFC, they are needed for eIDAS2 and EUDI Wallet alignment and Qualified Electronic Attestation of Attributes (QEAAs) issuance, according to [ETSI TS 119 472-1 v1.2.1](https://www.etsi.org/deliver/etsi_ts/119400_119499/11947201/01.02.01_60/ts_11947201v010201p.pdf).\n\n## Current behaviour\n\nThe `JWTHeader` class only supports the `x5c` header.\n\n## Expected behaviour\n\nThe following JWT headers should be configurable as well:\n - `x5u`\n - `x5t`\n - `x5t#S256`\n\n## Motivation\n\nAccording to TS 119 472-1 §7.6.2 and TS 119 472-1 §6.6.2, Qualified EAAs shall include these fields in the credential protected header. Furthermore, the lack of the `x5u` header prevents interoperability in cloud-signing scenarios where certificates are stored externally (e.g. in a HSM). This header is also needed for eIDAS2 compliance.\n\nIn addition to this, the `x5t` and `x5t#S256` headers allow the recipients to validate that the certificate referenced through the `x5u` header matches the expected certificate.\n","author":{"url":"https://github.com/DavSanOl","@type":"Person","name":"DavSanOl"},"datePublished":"2026-05-12T15:27:08.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":2},"url":"https://github.com/32/one-core/issues/32"}