[java-idp-plugin-vci] branch main updated: Improve readability
Codeberg
noreply at shibboleth.net
Wed Sep 30 18:03:00 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/da445f5970e8be868625083ea7fafb5aba0092f5
The following commit(s) were added to refs/heads/main by this push:
new da445f5 Improve readability
da445f5 is described below
commit da445f5970e8be868625083ea7fafb5aba0092f5
Author: Janne Lauros <janne.lauros at csc.fi>
AuthorDate: Wed Sep 30 21:02:36 2026 +0300
Improve readability
---
README.md | 48 ++++++++++++++++++++++++++----------------------
1 file changed, 26 insertions(+), 22 deletions(-)
diff --git a/README.md b/README.md
index a00199e..ec87e06 100644
--- a/README.md
+++ b/README.md
@@ -347,7 +347,7 @@ below. Without `vc+sd-jwt` credentials the file is not needed.
#### Settings of your own, per credential
Member `_issuance_configuration` is not published. It states how long a credential is valid,
-what it says issued it and whether it goes on a Status List.
+which issuer identifier it carries and whether it goes on a Status List.
It goes inside the credential's own configuration, next to `format` and `vct`:
@@ -419,8 +419,8 @@ nothing is issued.
cannot be revoked. Use it for short lived credentials.
A credential that states nothing goes on the list. Set
-`openidvci.status-list.includeByDefault` to `false` in *conf/openid-vci.properties* to turn that
-round and make the Status List something each credential opts into with `"status_list": true`.
+`openidvci.status-list.includeByDefault` to `false` in *conf/openid-vci.properties*. Then only a
+credential with `"status_list": true` goes on the list.
##### Which setting wins
@@ -467,8 +467,9 @@ endpoints go to the anonymous relying party. Both flows below need it:
</details>
-The templates of *static/* name your host already, they are evaluated against the issuer of the
-OP. One thing you need to add is the credential scopes in `scopes_supported` of
+You do not need to write your host name into the templates of *static/*. They use `$issuer`,
+`$baseUrl` and `$host`, and these are filled in from `idp.oidc.issuer` of *conf/oidc.properties*.
+One thing you need to add is the credential scopes in `scopes_supported` of
*static/oauth-authorization-server.json*, a wallet of the code flow asks a credential by scope:
```json
@@ -717,8 +718,9 @@ in the same *metadata/oidc-client.json* as the clients above:
</details>
Note the `scope` value. Every configuration id you want to be requestable by scope needs to be
-here. `grant_types` has the pre-authorized code grant as well, as the same wallet is usually
-also the one that redeems an offer. `audience` needs `credentials` for wallets that request
+here. A wallet needs the pre-authorized code grant in `grant_types` only if it sends its own
+`client_id` to the token endpoint in the pre-authorized code flow. The example has it to show
+that case. `audience` needs `credentials` for wallets that request
without `openid` in `scope`, the authorization endpoint rejects those when the client has no
audience.
@@ -790,8 +792,8 @@ read the real attributes of the user:
One attribute serves both credentials. Every `AttributeEncoder` of the definition becomes a
claim of its own name, so the same claim list is found with either configuration id and the
-script is written once. Mind which name goes where: the encoders name the credentials and
-everything else, `idp.oidc.encodedAttributes` and the filter policy, names the attribute.
+script is written once. The encoder names are credential configuration ids.
+`idp.oidc.encodedAttributes` and the filter policy use the attribute id.
Then you tell the OP plugin to embed the attribute into the access token in
*conf/oidc.properties*:
@@ -973,7 +975,7 @@ Cache-Control: no-store
</details>
The `id` is the month. You may give it also with the `~` part copied from the credential, a slot
-belongs to the month whatever the credential says issued it.
+belongs to the month whatever the issuer identifier of the credential.
Revoking is idempotent and it goes one way only. Nothing in the plugin turns a slot back to
valid. The revoke endpoint does **not** check that the caller issued the credential that holds
@@ -1018,7 +1020,7 @@ a wrong URL.
### Step 2: Add a did:web credential
Next we add a credential that is named by the `did:web` of this deployment,
-`did:web:issuer.example.org`. The identifier is derived from the issuer of the OP. Unlike
+`did:web:issuer.example.org`. The identifier is formed from the host of `idp.oidc.issuer`. Unlike
did:jwk it stays the same when the signing key changes, which matters in
[Step 6](#step-6-rolling-the-signing-key).
@@ -1173,7 +1175,7 @@ curl -u 'offer-caller:CHANGE-ME' \
### Step 3: Add a plain url credential
-Third credential is named by the issuer of the OP as such, `https://issuer.example.org`. A
+Third credential has the value of `idp.oidc.issuer` as its issuer, `https://issuer.example.org`. A
verifier finds the key from JWT VC issuer metadata, `/.well-known/jwt-vc-issuer`, which points to
the keyset of the OP.
@@ -1205,7 +1207,7 @@ The credential in *metadata/verifiable-credentials.json* is like the one of Step
}
```
-`url` is a keyword for the issuer of the OP. You may also write the url itself.
+`url` stands for the value of `idp.oidc.issuer`. You may also write the url itself.
Add **OAuth.JWTVCIssuer** to the anonymous relying party:
@@ -1261,8 +1263,8 @@ What is new:
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. The IdP does not start with the federation
-import and without the list.
+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:
@@ -1410,7 +1412,7 @@ put **first** in the list. The key needs a name, `p:keyNames`, for the did:web d
</util:list>
```
-The chain is emitted whenever the issuer of the signed thing is an https url, there is no
+The chain is emitted whenever the issuer of the credential, Status List Token or metadata is an https url, there is no
switch for it. That means the url credential of Steps 3 and 4 now carries `x5c` too, and no
`kid`. A verifier of it moves from `/.well-known/jwt-vc-issuer` to the chain. The did:jwk and
did:web credentials do not carry a chain, their identifier resolves the key. This is a key
@@ -1661,8 +1663,8 @@ identifier of the credential. The configuration is the same for all:
start signing with it.
A key that is in the list but does not sign is still published in the did:web document and in
-the Entity Configuration, and it still signs the Status List Tokens of the credentials it
-signed, when the identifier names the key.
+the Entity Configuration. For did:jwk credentials it also still signs the Status List Tokens
+of the credentials it signed.
| Identifier | What happens when the key changes |
|---|---|
@@ -2209,12 +2211,14 @@ The file comes with the plugin and is loaded automatically.
| `/.well-known/did.json` | `/idp/profile/did/document` | none, formed from the signing keys |
| `/.well-known/openid-federation` | `/idp/profile/oidfed/entity-configuration` | of the federation plugin |
-The templates are Velocity, `$issuer`, `$baseUrl` and `$host` come from the issuer of the OP.
+The templates are Velocity, `$issuer`, `$baseUrl` and `$host` are filled in from
+`idp.oidc.issuer` of *conf/oidc.properties*.
`credential_configurations_supported` is added from *metadata/verifiable-credentials.json*. The
Credential Issuer metadata endpoint answers `500 server_error` when `credential_endpoint` or
-`credential_configurations_supported` is missing. `batch_credential_issuance.batch_size` is read
-back as the batch size. `token_endpoint` of the authorization server metadata is the VCI one,
-the `/.well-known/openid-configuration` of the OP does not describe it.
+`credential_configurations_supported` is missing. `batch_credential_issuance.batch_size` is the
+most proofs a credential request may carry, it overrides `batchSize` of the profile.
+`token_endpoint` is the token endpoint of this plugin. The OP's
+`/.well-known/openid-configuration` has the OP's own token endpoint.
`dpop_signing_alg_values_supported` should be in step with `idp.oauth2.dpop.proofAlgorithms` of
*conf/oidc.properties*. `require_pushed_authorization_requests` and
`code_challenge_methods_supported` describe the OP, they are set on **OIDC.SSO**.
--
To stop receiving notification emails like this one, please contact
the administrator of this repository.
More information about the commits
mailing list