[java-idp-plugin-vci] branch main updated: In example, start using own key list earlier

[Codeberg]

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/e380f72e5c88ddd738ff97e4fcfd2ef384ffe9eb

The following commit(s) were added to refs/heads/main by this push:
     new e380f72  In example, start using own key list earlier
e380f72 is described below

commit e380f72e5c88ddd738ff97e4fcfd2ef384ffe9eb
Author: Janne Lauros <janne.lauros at csc.fi>
AuthorDate: Thu Oct 1 08:29:07 2026 +0300

    In example, start using own key list earlier
---
 README.md | 60 ++++++++++++++++++++++++++++++------------------------------
 1 file changed, 30 insertions(+), 30 deletions(-)

diff --git a/README.md b/README.md
index 8c820f2..95fd2bc 100644
--- a/README.md
+++ b/README.md
@@ -241,6 +241,10 @@ This chapter builds one deployment in steps. Every step adds something to the pr
 tells only what is new. The examples are from a running test deployment so they fit together,
 but it is not guaranteed that they work for you as such.
 
+Before you start, the OP needs an EC signing key. A normal installation of the OP plugin has one,
+*credentials/idp-signing-es.jwk*. Steps 1 to 4 sign with it. The plugin signs credentials with
+EC keys only and does not use the RSA key of the OP.
+
 1. A did:jwk credential with both flows and the Status List. Signed with the key of the OP.
 2. A second credential, did:web.
 3. A third credential, the issuer is the plain url.
@@ -1068,6 +1072,7 @@ What is new:
 - the did:web document is published at `/.well-known/did.json`
 - the credential header `kid` is a DID URL, `did:web:issuer.example.org#<kid of the key>`
 - the Status List url of the credential ends with `~did-web`
+- the plugin gets a signing key list of its own, with the EC key of the OP only
 
 The credential goes next to the two of Step 1 in *metadata/verifiable-credentials.json*:
 
@@ -1147,8 +1152,27 @@ and wire it in *etc/jetty-rewrite-rules.xml*:
 </Configure>
 ```
 
-The document has no file behind it. It is formed from the keys that sign credentials and Status
-List Tokens. We still sign with the keys of the OP, so it lists those, also the RSA key.
+The document has no file behind it. It is formed from the keys of
+**openidvci.SigningCredentials**. Without that list it would have all the signing keys of the OP,
+also the RSA key. In *conf/openid-vci-credentials.xml* the EC key of the OP is defined again from
+the same file and put in the list. Nothing changes in signing:
+
+```xml
+<bean id="openidvci.OPESSigningCredential" parent="shibboleth.JWKCredential"
+    p:resource="%{idp.signing.oidc.es.key}" />
+
+<util:list id="openidvci.SigningCredentials">
+    <ref bean="openidvci.OPESSigningCredential" />
+</util:list>
+```
+
+Import the file into *conf/global.xml*. The Entity Configuration of
+[Step 4](#step-4-make-the-url-credential-an-openid-federation-credential) does not see beans of
+*conf/credentials.xml*:
+
+```xml
+<import resource="openid-vci-credentials.xml"/>
+```
 
 <details>
 <summary>Example of the document at /.well-known/did.json</summary>
@@ -1182,7 +1206,7 @@ List Tokens. We still sign with the keys of the OP, so it lists those, also the
 
 </details>
 
-A key needs a name to be listed, the `kid` of a JWK key. The keys of the OP have one.
+A key needs a name to be listed, the `kid` of a JWK key. The EC key of the OP has one.
 
 To make the credential requestable, the same small additions for both flows:
 
@@ -1297,32 +1321,8 @@ What is new:
   metadata and the credential signing keys
 - the url credential carries `"fed": "https://issuer.example.org"`, the other credentials not
 
-#### Signing key
-
-The Entity Configuration publishes the keys credentials are signed with, and it reads them from
-**openidvci.SigningCredentials**. The keys of the OP are not visible to it, so the list has to
-be defined even if the signing key stays the same. If the federation file is imported and the
-list is not defined, the IdP does not start.
-
-In *conf/openid-vci-credentials.xml* the EC key of the OP is defined again from the same file and
-put in the list. Nothing changes in signing:
-
-```xml
-<bean id="openidvci.OPESSigningCredential" parent="shibboleth.JWKCredential"
-    p:resource="%{idp.signing.oidc.es.key}" />
-
-<util:list id="openidvci.SigningCredentials">
-    <ref bean="openidvci.OPESSigningCredential" />
-</util:list>
-```
-
-Import the file into *conf/global.xml*. Normally it would go to *conf/credentials.xml*, but the
-Entity Configuration is published from the root context and it does not see beans of
-*conf/credentials.xml*:
-
-```xml
-<import resource="openid-vci-credentials.xml"/>
-```
+The Entity Configuration publishes the keys of **openidvci.SigningCredentials** of Step 2. If
+the federation file is imported and the list is not defined, the IdP does not start.
 
 #### Federation
 
@@ -1336,7 +1336,7 @@ idp.oidfed.entityID = https://issuer.example.org
 
 Nothing checks that the two match, it is your responsibility.
 
-Import the federation file into *conf/global.xml*, after the import above:
+Import the federation file into *conf/global.xml*, after the import of Step 2:
 
 ```xml
 <import resource="openid-vci-oidfed.xml"/>

-- 
To stop receiving notification emails like this one, please contact
the administrator of this repository.