[java-idp-plugin-vci] branch main updated: Remove unnessary comments
Codeberg
noreply at shibboleth.net
Wed Sep 2 13:06:53 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/48b02e91962d87ba369a5bc91139b32f80f7a935
The following commit(s) were added to refs/heads/main by this push:
new 48b02e9 Remove unnessary comments
48b02e9 is described below
commit 48b02e91962d87ba369a5bc91139b32f80f7a935
Author: Janne Lauros <janne.lauros at csc.fi>
AuthorDate: Wed Sep 2 16:06:43 2026 +0300
Remove unnessary comments
---
.../openidvci/conf/openid-vci-credentials.xml | 86 ----------------------
.../plugin/openidvci/conf/openid-vci-oidfed.xml | 82 ---------------------
2 files changed, 168 deletions(-)
diff --git a/openid-vci-impl/src/main/resources/org/geant/shibboleth/plugin/openidvci/conf/openid-vci-credentials.xml b/openid-vci-impl/src/main/resources/org/geant/shibboleth/plugin/openidvci/conf/openid-vci-credentials.xml
index 11c82b3..5377ffa 100644
--- a/openid-vci-impl/src/main/resources/org/geant/shibboleth/plugin/openidvci/conf/openid-vci-credentials.xml
+++ b/openid-vci-impl/src/main/resources/org/geant/shibboleth/plugin/openidvci/conf/openid-vci-credentials.xml
@@ -9,51 +9,6 @@
default-init-method="initialize" default-destroy-method="destroy">
- <!--
- Signing keys of this plugin. Nothing here is active by default: Credentials are signed
- with the OP's own response signing credentials, the ones in
- shibboleth.oidc.SigningCredentials, and keeping it that way needs nothing to be done.
- Uncomment below whichever function you want to give a key of its own.
-
- Two functions of this plugin sign, and each of them can have its own key:
-
- Credential signing this file, openidvci.SigningCredentials
- Read by a wallet or verifier that has no relation to your deployment, long after
- issuing. Needs publishing if separated, see "Publishing" below.
-
- Status List Token signing this file, oauth.statuslist.SigningCredentials
- Read by the same verifiers. Constrained, see the section below.
-
- The OP's own response signing credentials, shibboleth.oidc.SigningCredentials in
- conf/oidc-credentials.xml, are what both fall back to.
-
- The defaults share one key across these because a plugin cannot generate keys for you.
- Separating them narrows what rotating or losing a key affects, which is the reason to
- bother. Generate each one with bin/jwtgen.sh, the same way as the OP's own keys.
- -->
-
- <!--
- Import this file into conf/credentials.xml.
-
- Import it into conf/global.xml instead if you state this deployment in OpenID
- Federation, see conf/openid-vci-oidfed.xml. Credential signing reads the list either
- way, publishing it in an Entity Configuration only works from the root context. The two
- go together: the federation file alone refuses to start without the list.
-
- Import it in ONE place, not both. The relying party service is a child of the root
- context and reads beans from it, so everything signing Credentials still finds the list
- when it is declared in conf/global.xml. Importing this file in both places declares the
- same bean ids twice, and the child copies shadow the root ones: Credential signing would
- then use one set of credential objects and the Entity Configuration another. Reloading
- conf/credentials.xml could move signing to a new key while vc_issuer still states the old
- one, which is the drift this arrangement exists to prevent.
-
- The cost of moving the import is reload. conf/credentials.xml belongs to the relying party
- service, which is reloadable, so a key listed there can be changed without a restart.
- conf/global.xml is the root context and is not reloadable. Federating therefore makes key
- changes a restart, which is why the import location is left as credentials.xml by default.
- -->
-
<!--
Signing key of Verifiable Credentials only. Must be EC key, signing actions support
nothing else, and it should match one of the algorithms you advertise in
@@ -78,17 +33,6 @@
</util:list>
-->
- <!--
- Signing key of Status List Tokens. A status list is a general purpose mechanism and does
- not serve only Verifiable Credentials, so it has its own key where it can.
-
- IT CANNOT WHILE THE ISSUER IS A did:jwk, which is the default. A Status List Token names
- the same issuer as the Credentials referring to it, and while that issuer is a did:jwk
- the issuer IS the signing key: a separate key would make your Credentials point at a
- status list that reads as issued by somebody else. So uncomment these two only once
- openidvci.issuer in conf/openid-vci.properties names a real issuer. Until then the
- Credential signing key above signs Status List Tokens too.
- -->
<!--
<bean id="oauth.statuslist.DefaultESSigningCredential" parent="shibboleth.JWKCredential"
p:resource="%{idp.signing.oauth.statuslist.es.key}" />
@@ -98,34 +42,4 @@
</util:list>
-->
- <!--
- Publishing.
-
- A wallet or verifier finds your public key from the key set the OP publishes in its
- jwks_uri. That key set holds shibboleth.oidc.SigningCredentials, so the key defined
- above is NOT published. Credentials signed with it CANNOT be verified before you say
- otherwise.
-
- This matters only if you separated the key above. Publishing it in an OpenID Federation
- Entity Configuration is one way, see
- conf/openid-vci-oidfed.xml. Publishing it in the OP's key set is the other: define
- shibboleth.oidc.SigningCredentialsToPublish in oidc-credentials.xml. That bean REPLACES
- the published set, it does not add to it, so it must list the OP's own signing
- credentials too or clients can no longer verify id tokens. The list looks like this:
-
- <util:list id="shibboleth.oidc.SigningCredentialsToPublish">
- <ref bean="shibboleth.oidc.DefaultRSSigningCredential" />
- <ref bean="shibboleth.oidc.DefaultESSigningCredential" />
- <ref bean="openidvci.DefaultESSigningCredential" />
- </util:list>
-
- Note that the same list is also the set of keys trusted when validating JWTs your
- deployment has issued to itself, logout tokens for example. The Credential signing key
- becomes trusted there too. Publishing through the federation avoids that, and is why
- ...ToPublish is the second choice rather than the first.
-
- Publish the key before you start signing with it. A verifier that fetched the key set
- earlier may still have the old one cached.
- -->
-
</beans>
diff --git a/openid-vci-impl/src/main/resources/org/geant/shibboleth/plugin/openidvci/conf/openid-vci-oidfed.xml b/openid-vci-impl/src/main/resources/org/geant/shibboleth/plugin/openidvci/conf/openid-vci-oidfed.xml
index a7fd47e..f9a92dc 100644
--- a/openid-vci-impl/src/main/resources/org/geant/shibboleth/plugin/openidvci/conf/openid-vci-oidfed.xml
+++ b/openid-vci-impl/src/main/resources/org/geant/shibboleth/plugin/openidvci/conf/openid-vci-oidfed.xml
@@ -9,73 +9,6 @@
default-init-method="initialize" default-destroy-method="destroy">
- <!--
- This file states in OpenID Federation that this deployment is a Credential Issuer. It
- should be imported into conf/global.xml.
-
- IMPORT IT ONLY IF THE OpenID Federation PLUGIN IS INSTALLED. The bean below implements
- an interface that ships with that plugin, so without it the bean cannot be created and
- the IdP will not start.
-
- Nothing here is active by default, importing the file is what turns it on. Once
- imported, the federation module picks the bean up on its own, there is no list of
- decorators to add it to. It collects every bean of the decorator type it can see.
-
- Three entity types are stated:
-
- openid_credential_issuer
- The Credential Issuer metadata, the same document /.well-known/openid-credential-issuer
- serves. It comes from the same resolver, so the two cannot drift apart. A member
- wanted only in the federation, "authorization_endpoint" for example, is added to
- static/openid-credential-issuer.json and needs nothing here.
-
- vc_issuer
- A JWK Set of the keys Credentials are signed with, public halves only. This is how
- a verifier finds the key: it reads a Credential long after issuing, and has no
- relation to this deployment.
-
- The keys are listed below, and the list has to be here rather than resolved from the
- request. An entity configuration describes the entity, and the federation module
- caches one document per deployment, so nothing in it may depend on a relying party.
-
- federation_entity
- display_name and logo_uri, taken from the display properties of the Credential
- Issuer metadata. Only members the federation module's own entity configuration
- metadata does not already carry are filled. Set decorateFederationEntity to false
- to state federation_entity entirely in that file instead.
- -->
-
- <!--
- The keys stated in vc_issuer are read from bean "openidvci.SigningCredentials", the same
- bean the Credential signing configuration reads. One declaration, so what is published
- is what signs.
-
- THAT BEAN HAS TO BE DECLARED WHERE THE ROOT CONTEXT READS IT, which means importing
- conf/openid-vci-credentials.xml into conf/global.xml rather than into conf/credentials.xml.
- Credential signing lives in the reloadable relying party service, a child of the root
- context, so it still finds the bean; the other way around does not work, which is why
- this file cannot simply point at openidvci.SigningConfiguration. The plugin refuses to
- start if the bean is not there: a Credential Issuer stating no key in a federation is a
- deployment error, not something to find out from a verifier that cannot read a Credential.
-
- The plugin's default, sharing the OP's response signing credentials, cannot be read here
- directly: bean shibboleth.oidc.SigningCredentialsFactory lives in the relying party
- service. The keys behind it can be, though. They are JWK files named by properties, so
- declaring the list against the same property keeps one source:
-
- <util:list id="openidvci.SigningCredentials">
- <bean parent="shibboleth.JWKCredential" p:resource="%{idp.signing.oidc.es.key}" />
- </util:list>
-
- List the EC key only. Credentials are signed with EC algorithms and nothing else, so an
- RSA key in this list would be stated in vc_issuer as a key that signs Credentials while
- never signing one. Note also that this pins the key: rotating the OP's key by pointing
- conf/oidc-credentials.xml at another resource would leave this list behind.
-
- Preferring a key of your own is still the better answer. A key published in a federation
- as a Credential signing key should sign Credentials and nothing else, so generate one
- with bin/jwtgen.sh and enable it in conf/openid-vci-credentials.xml.
- -->
<bean id="openidvci.oidfed.CredentialIssuerEntityConfigurationMetadataDecorator"
class="org.geant.shibboleth.plugin.openidvci.oidfed.impl.CredentialIssuerEntityConfigurationMetadataDecorator"
p:id="openidvci.oidfed.CredentialIssuerEntityConfigurationMetadataDecorator"
@@ -83,19 +16,4 @@
p:credentialSigningCredentials="#{getObject('openidvci.SigningCredentials')}"
p:decorateFederationEntity="%{openidvci.oidfed.decorateFederationEntity:true}" />
- <!--
- The entity statement itself is signed with the federation module's own key, not with the
- keys above. Section 5.2.1 of OpenID Federation names them as distinct: the federation
- key identifies the entity to the federation, the keys above let a verifier read a
- Credential. Keep them separate.
-
- Worth checking once, because the federation module signs with
- shibboleth.oidfed.SigningCredentials and falls back to shibboleth.oidc.SigningCredentials
- when that is undefined. A Credential signing key that is also in the OP's list therefore
- ends up trusted to sign entity statements. It shows in the published statement: the top
- level "jwks" claim is the Federation Entity Keys, and a Credential signing key belongs in
- metadata.vc_issuer.jwks only. Declaring shibboleth.oidfed.SigningCredentials explicitly
- separates them.
- -->
-
</beans>
--
To stop receiving notification emails like this one, please contact
the administrator of this repository.
More information about the commits
mailing list