[java-idp-plugin-vci] 02/02: HAIP section cleaned up. References to conformance suite removed
Codeberg
noreply at shibboleth.net
Mon Sep 28 16:20:59 UTC 2026
This is an automated email from the git hooks/post-receive script.
codeberg pushed a commit to branch main
in repository java-idp-plugin-vci.
View the commit online:
https://codeberg.org/Shibboleth/java-idp-plugin-vci/commit/a97fa006c8dc9b8eb8652e308166e66730eca9f1
commit a97fa006c8dc9b8eb8652e308166e66730eca9f1
Author: Janne Lauros <janne.lauros at csc.fi>
AuthorDate: Mon Sep 28 19:20:43 2026 +0300
HAIP section cleaned up. References to conformance suite removed
---
README.md | 154 +++++++++++++++++++++++++++++++-------------------------------
1 file changed, 77 insertions(+), 77 deletions(-)
diff --git a/README.md b/README.md
index 63fe66f..a00199e 100644
--- a/README.md
+++ b/README.md
@@ -207,8 +207,7 @@ but it is not guaranteed that they work for you as such.
2. A second credential, did:web.
3. A third credential, the issuer is the plain url.
4. The third credential is made an OpenID Federation credential.
-5. A fourth credential, for a HAIP wallet. Signing key gets a certificate chain. The wallet is
- the OpenID Foundation conformance suite.
+5. A fourth credential, for a HAIP wallet. Signing key gets a certificate chain.
6. Rolling the signing key to the next one.
For steps 1 to 4 the wallet is [Paradym](https://paradym.id). At the end the installation
@@ -1370,23 +1369,21 @@ metadata file of the federation module instead.
Last credential is for a HAIP wallet. HAIP wants the issuer key as a certificate chain in the
`x5c` header of the credential, of the Status List Token and of signed metadata. The wallet
-authenticates with a Wallet Attestation and its key proof carries a key attestation. The wallet
-here is the OpenID Foundation conformance suite.
+authenticates with a Wallet Attestation and its key proof carries a key attestation.
-What is new:
+What you configure:
-- the signing key has a certificate and a chain, and it signs first
-- the HAIP credential is a url credential, `cnf` carries the `jwk` of the wallet
-- key attestation is required for the HAIP credential
-- the conformance suite is a wallet client with `attest_jwt_client_auth`
-- Credential Issuer metadata is published also signed
+- a signing key with a certificate chain, used first
+- a url credential, only a url credential carries the chain in `x5c`
+- key attestation required for the credential, and the attester CA you trust
+- the wallet as a client with `attest_jwt_client_auth`
+- signed Credential Issuer metadata
#### Certificate chain
-You need an EC signing key, its certificate and the chain above it, from a CA of your own or of
-a 3rd party. The leaf names your host as a dNSName and as a URI in SAN, it is not a CA and it is
-not self-signed. The chain has the leaf and the issuing CA, not the root. The root is what a
-verifier trusts. Below they are *credentials/vci-signing.key*, *credentials/vci-signing.crt* and
+You need an EC signing key, its certificate and the chain above it, without the root, see
+[HAIP issuer key resolution](https://openid.net/specs/openid4vc-high-assurance-interoperability-profile-1_0-final.html#issuer-key-resolution).
+Below they are *credentials/vci-signing.key*, *credentials/vci-signing.crt* and
*credentials/vci-issuing-ca.crt*.
In *conf/openid-vci-credentials.xml* the key is defined with its certificates, leaf first, and
@@ -1471,12 +1468,16 @@ attestation required:
</details>
+`key_storage` and `user_authentication` of `key_attestations_required` list the attack resistance
+the wallet has to attest for its key storage and user authentication. `iso_18045_moderate` is
+resistance to attack potential Moderate, see
+[attack potential resistance](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-attack-potential-resistance)
+for the other values.
+
#### Attestations
Key attestations and Wallet Attestations are signed by an attester, the wallet provider. You
-trust the certificate of the attester CA. For the conformance suite you need an attester key and
-certificate under a CA you have. The attester key and its certificate go to the suite
-configuration below, the CA certificate to *conf/global.xml*:
+trust the certificate of the attester CA of the wallet provider, in *conf/global.xml*:
```xml
<util:list id="openidvci.KeyAttestationTrustAnchors">
@@ -1517,11 +1518,9 @@ does not know. Give the OAuth endpoints of the OP the same flow in *conf/oidc.pr
idp.oauth2.authn.flows = OpenIDVCIClient
```
-#### The conformance suite as a client
+#### The HAIP wallet as a client
-The suite runs two clients, the second one only differs in the redirect uri. The client id is
-the `sub` of the Wallet Attestation the suite makes. In *metadata/oidc-client.json*, `shibVciTest`
-being the alias of your test plan:
+The client id is the `sub` of the Wallet Attestation of the wallet. In *metadata/oidc-client.json*:
<details>
<summary>Example snippet of metadata/oidc-client.json</summary>
@@ -1530,19 +1529,9 @@ being the alias of your test plan:
[
...
{
- "client_id": "conformance_client_1",
- "client_name": "OpenID Conformance Suite",
- "redirect_uris": ["https://www.certification.openid.net/test/a/shibVciTest/callback"],
- "scope": "openid GeantIncubatorDiploma_HAIP",
- "audience": "credentials",
- "token_endpoint_auth_method": "attest_jwt_client_auth",
- "response_types": ["code"],
- "grant_types": ["authorization_code", "urn:ietf:params:oauth:grant-type:pre-authorized_code"]
- },
- {
- "client_id": "conformance_client_2",
- "client_name": "OpenID Conformance Suite",
- "redirect_uris": ["https://www.certification.openid.net/test/a/shibVciTest/callback?dummy1=lorem&dummy2=ipsum"],
+ "client_id": "haip-wallet",
+ "client_name": "HAIP Wallet",
+ "redirect_uris": ["https://wallet.example.org/callback"],
"scope": "openid GeantIncubatorDiploma_HAIP",
"audience": "credentials",
"token_endpoint_auth_method": "attest_jwt_client_auth",
@@ -1569,7 +1558,7 @@ allows an authorization code at most 60 seconds. The OP plugin default is five m
<util:list id="shibboleth.RelyingPartyOverrides">
...
<bean parent="RelyingPartyByName"
- c:relyingPartyIds="#{{'conformance_client_1','conformance_client_2'}}">
+ c:relyingPartyIds="#{{'haip-wallet'}}">
<property name="profileConfigurations">
<list>
<bean parent="OIDC.SSO"
@@ -1596,54 +1585,68 @@ DPoP settings are left to their defaults, so a DPoP nonce is required.
DPoP, see [RFC 9449 10.1](https://www.rfc-editor.org/rfc/rfc9449#section-10.1).
Add `<AttributeEncoder xsi:type="oidc:OIDCString" name="GeantIncubatorDiploma_HAIP" />` to the
-attribute definition and release the attribute also to the two conformance clients in
+attribute definition and release the attribute also to the HAIP wallet in
*conf/attribute-filter.xml*.
-Advertise the rest in *static/oauth-authorization-server.json*. `GeantIncubatorDiploma_HAIP` goes to
-`scopes_supported` as before and these are added:
+The whole *static/oauth-authorization-server.json* after this step. `token_endpoint_auth_methods_supported`
+lists the methods your `tokenEndpointAuthMethods` allow on the token and PAR endpoints, here `none`
+for Paradym and `attest_jwt_client_auth` for the HAIP wallet:
+
+<details>
+<summary>Example contents of static/oauth-authorization-server.json</summary>
```json
{
- ...
+ "issuer":"$issuer",
+ "authorization_endpoint":"$baseUrl/idp/profile/oidc/authorize",
+ "pushed_authorization_request_endpoint":"$baseUrl/idp/profile/oauth2/pushed-authorization",
+ "require_pushed_authorization_requests":true,
+ "token_endpoint":"$baseUrl/idp/profile/openid/vci/token",
+ "jwks_uri":"$baseUrl/idp/profile/oidc/keyset",
"token_endpoint_auth_methods_supported":[
"none",
- "client_secret_basic",
- "client_secret_post",
- "client_secret_jwt",
"attest_jwt_client_auth"
],
- "client_attestation_signing_alg_values_supported":[ "ES256" ],
- "client_attestation_pop_signing_alg_values_supported":[ "ES256" ],
+ "client_attestation_signing_alg_values_supported":[
+ "ES256"
+ ],
+ "client_attestation_pop_signing_alg_values_supported":[
+ "ES256"
+ ],
"authorization_response_iss_parameter_supported":true,
- ...
-}
-```
-
-#### Suite configuration
-
-The test plan of the suite is configured with JSON. The parts that come from this deployment:
-
-```json
-{
- "alias": "shibVciTest",
- "vci": {
- "credential_issuer_url": "https://issuer.example.org",
- "credential_configuration_id": "GeantIncubatorDiploma_HAIP"
- },
- "credential": {
- "trust_anchor_pem": "<vci-root-ca.crt as one line, newlines as \\n>",
- "status_list_trust_anchor_pem": "<the same>"
- },
- "client_attestation": {
- "issuer": "https://wallet-provider.example.org",
- "attester_jwks": { "keys": [ "<attester private key as JWK, attester certificate in x5c>" ] },
- "key_attestation_jwks": { "keys": [ "<the same>" ] }
- }
+ "response_types_supported":[
+ "code"
+ ],
+ "grant_types_supported":[
+ "authorization_code",
+ "urn:ietf:params:oauth:grant-type:pre-authorized_code"
+ ],
+ "code_challenge_methods_supported":[
+ "S256"
+ ],
+ "dpop_signing_alg_values_supported":[
+ "ES256",
+ "ES384",
+ "ES512",
+ "PS256",
+ "PS384",
+ "PS512"
+ ],
+ "scopes_supported":[
+ "openid",
+ "GeantIncubatorDiploma_SDJWT",
+ "GeantIncubatorDiploma_W3C",
+ "GeantIncubatorDiploma_DIDWEB",
+ "GeantIncubatorDiploma_URL",
+ "GeantIncubatorDiploma_HAIP"
+ ],
+ "authorization_details_types_supported":[
+ "openid_credential"
+ ]
}
```
-The client ids of the suite are `conformance_client_1` and `conformance_client_2` as registered
-above.
+</details>
### Step 6: Rolling the signing key
@@ -1683,7 +1686,7 @@ is another key than the one of the credential.
| `GeantIncubatorDiploma_SDJWT`, `_W3C` | `did:jwk:…` | the identifier | no | Paradym |
| `GeantIncubatorDiploma_DIDWEB` | `did:web:issuer.example.org` | `/.well-known/did.json` | no | Paradym |
| `GeantIncubatorDiploma_URL` | `https://issuer.example.org` | `x5c`, earlier `/.well-known/jwt-vc-issuer` | yes | Paradym |
-| `GeantIncubatorDiploma_HAIP` | `https://issuer.example.org` | `x5c` | no | conformance suite |
+| `GeantIncubatorDiploma_HAIP` | `https://issuer.example.org` | `x5c` | no | HAIP wallet |
The whole *conf/relying-party.xml* is in [Relying party configuration](#relying-party-configuration)
and the whole *etc/jetty-rewrite-rules.xml* in [Discovery documents](#discovery-documents).
@@ -2275,10 +2278,7 @@ the `/.well-known/openid-configuration` of the OP does not describe it.
"token_endpoint":"$baseUrl/idp/profile/openid/vci/token",
"jwks_uri":"$baseUrl/idp/profile/oidc/keyset",
"token_endpoint_auth_methods_supported":[
- "none",
- "client_secret_basic",
- "client_secret_post",
- "client_secret_jwt"
+ "none"
],
"response_types_supported":[
"code"
@@ -2493,9 +2493,9 @@ The file as it is at the end of [First installation, by example](#first-installa
</property>
</bean>
- <!-- HAIP wallets, the conformance suite, authenticating with a Wallet Attestation -->
+ <!-- HAIP wallets, authenticating with a Wallet Attestation -->
<bean parent="RelyingPartyByName"
- c:relyingPartyIds="#{{'conformance_client_1','conformance_client_2'}}">
+ c:relyingPartyIds="#{{'haip-wallet'}}">
<property name="profileConfigurations">
<list>
<bean parent="OIDC.SSO"
--
To stop receiving notification emails like this one, please contact
the administrator of this repository.
More information about the commits
mailing list