feat(jans-auth): Add UDAP Authorization Server support for Janssen/Flex

A customer wants to use **Janssen/Flex** as a **UDAP Authorization Server** for healthcare/FHIR workflows.

UDAP, or **Unified Data Access Profiles**, extends OAuth 2.0 and OpenID Connect for secure, scalable, interoperable healthcare API transactions. A UDAP-capable Authorization Server needs to support dynamic onboarding of trusted client applications using signed software statements, X.509 certificates, PKI trust anchors, asymmetric client authentication, and UDAP-specific metadata discovery.

The customer specifically needs the Authorization Server to support:

- **Dynamic Client Registration** for trusted application onboarding.
- **PKI-based key binding** to legal entities / trusted organizations.
- **Asymmetric cryptographic client authentication**, for example client certificates, JWTs, and `private_key_jwt`.
- **Discovery, registration, authorization, and token request transactions** for client applications.
- **Metadata exchange** through `/.well-known/udap`.

Janssen/Flex already provides many of the OAuth/OIDC building blocks required for this use case:

- OAuth 2.0 / OpenID Connect Authorization Server.
- Dynamic Client Registration endpoint.
- Software Statement / SSA handling.
- `private_key_jwt` client authentication.
- JWKS / JWKS URI support.
- mTLS-related client authentication support.
- Client Registration interception scripts.

However, Janssen/Flex does not currently appear to provide a complete **UDAP profile layer** out of the box. The requested feature is to add UDAP-specific discovery, registration validation, certificate trust processing, replay protection, and FHIR/healthcare scope policy on top of the existing Janssen/Flex OAuth/OIDC foundation.

---

## Describe the solution you'd like

Add support for using **Janssen/Flex as a UDAP-compliant Authorization Server**.

At minimum, the implementation should support:

1. `/.well-known/udap` metadata endpoint.
2. UDAP Dynamic Client Registration.
3. Signed `software_statement` validation.
4. `x5c` certificate-chain validation.
5. Configurable UDAP trust anchors / CA bundles.
6. Replay protection for software statement `jti`.
7. Enforcement of `private_key_jwt` for UDAP-registered clients.
8. FHIR/healthcare scope policy validation.
9. Clear audit/debug logging for UDAP registration success and failure.

### Proposed high-level flow

```text
UDAP Client
|
| 1. GET /.well-known/udap
v
UDAP Metadata Endpoint
|
| 2. POST Dynamic Client Registration request
| including udap="1" and signed software_statement
v
Janssen/Flex Dynamic Client Registration Endpoint
|
| 3. UDAP validation layer / CLIENT_REGISTRATION script
| - validate software_statement
| - validate x5c certificate chain
| - validate configured trust anchor
| - validate iss/sub/aud/exp/iat/jti
| - validate scopes and grant types
| - enforce private_key_jwt
v
Janssen Client Store
|
| 4. Registered client uses private_key_jwt
v
Authorization Endpoint / Token Endpoint / FHIR APIs
```
---

## Suggested implementation phases

### Phase 1: Proof of Concept

Deliver:

- Static or configurable `/.well-known/udap` endpoint.
- UDAP-aware `CLIENT_REGISTRATION` script.
- Signed `software_statement` validation.
- `x5c` certificate chain validation against configured CA bundle.
- Enforcement of `private_key_jwt`.
- Basic FHIR scope allowlist.
- Successful client registration using UDAP DCR.
- Successful token request using `private_key_jwt` from the registered client.

### Phase 2: Productization

Deliver:

- Admin UI / TUI / config-api support for UDAP settings.
- Trust anchor management.
- CRL/OCSP revocation configuration.
- Replay cache for `jti`.
- Configurable signing algorithms.
- Configurable grant types and scopes.
- Audit/debug logging.
- Helm/cloud-native configuration support.
- VM deployment configuration support.
- Documentation and sample configuration.

### Phase 3: Advanced UDAP features

Deliver:

- Signed metadata support.
- Certifications and endorsements support.
- Tiered OAuth / trusted IdP workflows if required.
- UDAP conformance / test-tool compatibility.
- Example healthcare/FHIR deployment guide.

---

## Open questions for developers

1. Should `/.well-known/udap` be implemented directly in `jans-auth`, or exposed through a small companion service / reverse proxy route?
2. Should the first implementation be a sample `CLIENT_REGISTRATION` script or native product code?
3. How should trust anchors be stored and managed in VM deployments?
4. How should trust anchors be stored and managed in cloud-native Flex deployments?
5. Where should `jti` replay protection be stored: cache, persistence layer, or existing Janssen storage?
6. Should CRL/OCSP revocation checking be mandatory or configurable?
7. Should this be implemented as a generic Janssen feature or packaged as a Gluu Flex healthcare/UDAP profile?
8. Should certifications and endorsements be part of the initial implementation or deferred?
9. Should signed metadata be supported in the first release or deferred?
10. Which UDAP Security IG version should be the initial target: STU 1.x, STU 2.0.0, or current build?

## References

### UDAP / HL7 specifications

- HL7 UDAP Security Implementation Guide v2.0.0
https://hl7.org/fhir/us/udap-security/

- HL7 UDAP Discovery
https://hl7.org/fhir/us/udap-security/discovery.html

- HL7 UDAP General Requirements
https://hl7.org/fhir/us/udap-security/general.html

- UDAP Dynamic Client Registration
https://www.udap.org/udap-dynamic-client-registration.html

- UDAP Dynamic Client Registration STU1 details
https://www.udap.org/udap-dynamic-client-registration-stu1.html

- UDAP Certifications and Endorsements
https://www.udap.org/udap-certifications-and-endorsements.html

- UDAP B2B Health Apps Implementation Guide
https://www.udap.org/udap-ig-b2b-health-apps

- UDAP Consumer-Facing Health Apps Implementation Guide
https://www.udap.org/udap-ig-consumer-facing-health-apps

- HealthIT.gov Inferno UDAP Security Test Kit
https://fhir.healthit.gov/test-kits/udap-security/

### OAuth / IETF specifications

- RFC 7591: OAuth 2.0 Dynamic Client Registration Protocol
https://datatracker.ietf.org/doc/html/rfc7591

- RFC 7523: JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants
https://datatracker.ietf.org/doc/html/rfc7523

- RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens
https://www.rfc-editor.org/rfc/rfc8705.html

### Janssen/Flex documentation

- Janssen Dynamic Client Registration endpoint
https://docs.jans.io/head/janssen-server/auth-server/endpoints/client-registration/

- Janssen Software Statements
https://docs.jans.io/head/janssen-server/auth-server/client-management/software-statements/

- Janssen Client Registration Interception Script
https://docs.jans.io/nightly/script-catalog/client_registration/client-registration/

- Janssen Interception Scripts overview
https://docs.jans.io/head/janssen-server/developer/scripts/

- Janssen OpenBanking Client Registration script example
https://docs.jans.io/v1.16.0/script-catalog/client_registration/OpenBanking/client-registration/

---

## Summary

Janssen/Flex already has the core OAuth/OIDC foundation required for UDAP, including Dynamic Client Registration, software statement support, asymmetric client authentication, and registration-time interception scripts. The requested work is to add the UDAP-specific profile layer: `/.well-known/udap` discovery, UDAP DCR validation, X.509 trust-chain processing, replay protection, FHIR scope policy, and deployment/admin configuration.

The recommended first step is a PoC using a configurable UDAP metadata endpoint plus a `CLIENT_REGISTRATION` interception script. If successful, this can be productized as a native Janssen/Flex healthcare/UDAP feature.