[java-idp-plugin-vci] branch main updated: Improve readability

Codeberg noreply at shibboleth.net
Wed Sep 30 18:45:30 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/b195e25f94e8bf524a0fe8f4c53cc1224827ad75

The following commit(s) were added to refs/heads/main by this push:
     new b195e25  Improve readability
b195e25 is described below

commit b195e25f94e8bf524a0fe8f4c53cc1224827ad75
Author: Janne Lauros <janne.lauros at csc.fi>
AuthorDate: Wed Sep 30 21:45:16 2026 +0300

    Improve readability
---
 README.md | 38 +++++++++++++++++++-------------------
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/README.md b/README.md
index 472cd2b..8c820f2 100644
--- a/README.md
+++ b/README.md
@@ -255,7 +255,7 @@ releases did:jwk, did:web, plain url, OpenID Federation and HAIP credentials.
 
 ### Step 1: did:jwk credential, both flows
 
-First credential is named by `did:jwk`, which is the default. The issuer identifier is the key
+The issuer of the first credential is `did:jwk`, which is the default. The issuer identifier is the key
 itself and it travels in the credential, so there is nothing to publish for a verifier. The
 credential is signed with the EC key of the OP, *credentials/idp-signing-es.jwk* of a normal
 installation, and nothing about keys needs to be configured yet.
@@ -349,7 +349,7 @@ of the specification, per credential format. Below only the members that need ex
 
 </details>
 
-The configuration id, `GeantIncubatorDiploma_SDJWT` here, is used everywhere. A wallet names it
+The configuration id, `GeantIncubatorDiploma_SDJWT` here, is used everywhere. A wallet uses it
 in a credential request, it is the `scope` value and the claim values in the access token are
 keyed with it. Use exactly the same string in all places.
 
@@ -379,7 +379,7 @@ in it:
 
 </details>
 
-You publish it in the url the `@context` names, see [Metadata endpoints](#metadata-endpoints)
+You publish it at the url that is in `@context`, see [Metadata endpoints](#metadata-endpoints)
 below. Without `vc+sd-jwt` credentials the file is not needed.
 
 #### Settings of your own, per credential
@@ -872,7 +872,7 @@ cannot widen it.
 **File(s):** *conf/relying-party.xml*, *conf/openid-vci.properties*
 **Format:** Native Spring, Spring Properties
 
-Credentials this plugin issues carry a `status` claim that names one slot of a Status List, as
+Credentials this plugin issues carry a `status` claim that points to one slot of a Status List, as
 in [draft-ietf-oauth-status-list](https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/).
 The credential endpoint allocates a slot for every credential it signs, unless the credential
 is told not to take one.
@@ -900,7 +900,7 @@ the list of March 2027. As we need to keep track of credentials and revocation w
 to buckets per expiration.
 
 The part after `~` tells under which issuer identifier the credential was issued. A Status List
-Token has to name the same issuer as the credential. For `did:jwk` the part is the thumbprint
+Token has to have the same issuer as the credential. For `did:jwk` the part is the thumbprint
 of the signing key, as the identifier is the key. For `did:web` it is `did-web` and for the plain
 url `url`. It is still one list per month, whatever the identifier.
 
@@ -1057,7 +1057,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,
+Next we add a credential whose issuer is the `did:web` of this deployment,
 `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).
@@ -1191,7 +1191,7 @@ To make the credential requestable, the same small additions for both flows:
 - `<AttributeEncoder xsi:type="oidc:OIDCString" name="GeantIncubatorDiploma_DIDWEB" />` to the
   attribute definition of Step 1. The claims are the same, so the script does not change.
 
-And the offer of the pre-authorized code flow names the new id:
+And the offer of the pre-authorized code flow has the new id:
 
 ```bash
 curl -u 'offer-caller:CHANGE-ME' \
@@ -1287,7 +1287,7 @@ Scope, scopes supported, attribute encoder and offer as in Step 2, with
 ### Step 4: Make the url credential an OpenID Federation credential
 
 No new credential in this step. The deployment is stated as a Credential Issuer in OpenID
-Federation and the url credential of Step 3 names it. The federation itself, trust anchors,
+Federation and the url credential of Step 3 carries its Entity Identifier. The federation itself, trust anchors,
 authority hints and so on, is configured in the plugins of [Dependencies](#dependencies), see
 [OIDFEDCommon](https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/5601296385/OIDFEDCommon).
 
@@ -1706,18 +1706,18 @@ of the credentials it signed.
 
 | Identifier | What happens when the key changes |
 |---|---|
-| `did:jwk` | The identifier is the key, so it changes. New credentials name a new issuer. Old credentials verify on their own, the key is inside, but a verifier that trusts the issuer by its identifier has to be told the new one. The Status List url of an old credential names the old key by its thumbprint, and that list is signed with the old key. If the old key is not in the list anymore, the Status List Token of the old credentials is not served and they cannot be checked. |
-| `did:web` | The identifier stays. The did:web document lists every key of the list, each by its name, so the new key needs a name of its own. Old credentials name the old key by `kid` and it stays in the document as long as it is in the list. |
+| `did:jwk` | The identifier is the key, so it changes. New credentials have a new issuer. Old credentials verify on their own, the key is inside, but a verifier that trusts the issuer by its identifier has to be told the new one. The Status List url of an old credential has the thumbprint of the old key, and that list is signed with the old key. If the old key is not in the list anymore, the Status List Token of the old credentials is not served and they cannot be checked. |
+| `did:web` | The identifier stays. The did:web document lists every key of the list, each by its name, so the new key needs a name of its own. Old credentials have the `kid` of the old key and it stays in the document as long as it is in the list. |
 | url, no chain | The identifier stays. The key is found by `kid` from the keyset of the OP, so the new key goes to **shibboleth.oidc.SigningCredentialsToPublish** before it signs, and the old one stays there until its credentials have expired. |
-| url, with chain | The identifier stays. The credential carries its chain, a verifier trusts the root. A new leaf under the same CA needs nothing published. The Status List of url credentials does not name a key, it is signed with whatever key is first. |
+| url, with chain | The identifier stays. The credential carries its chain, a verifier trusts the root. A new leaf under the same CA needs nothing published. The Status List of url credentials is not tied to a key, it is signed with whatever key is first. |
 | OpenID Federation | The Entity Configuration publishes the keys of the list. Same as did:web. |
 
 So did:jwk is not good for a deployment that rotates keys and revokes credentials. Use it for
 testing and for credentials that live shorter than the key.
 
 Status List Tokens may be signed with a key of their own, **openidvci.status-list.SigningCredentials**.
-Do not do that while any credential is did:jwk, the Status List Token would name an issuer that
-is another key than the one of the credential.
+Do not do that while any credential is did:jwk, the issuer of the Status List Token
+would be another key than the issuer of the credential.
 
 ### What we have now
 
@@ -1736,15 +1736,15 @@ and the whole *etc/jetty-rewrite-rules.xml* in [Discovery documents](#discovery-
 **File(s):** *metadata/verifiable-credentials.json*, *metadata/oidc-client.json*, *conf/relying-party.xml*
 **Format:** JSON, Native Spring
 
-A wallet names the credential it wants in the
+A wallet tells which credential it wants in the
 [Credential Request](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-credential-request) in one of two ways, see
 [Section 3.3.4](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-identifying-credentials-bei) and the [Terminology](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#terminology):
 
 - `credential_configuration_id`, a key of `credential_configurations_supported` in your
-  [Credential Issuer metadata](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-credential-issuer-metadata-p). It names the kind of
+  [Credential Issuer metadata](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-credential-issuer-metadata-p). It is the kind of
   credential.
 - `credential_identifier`, one of the `credential_identifiers` this issuer returned in the
-  [token response](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-successful-token-response). It names one Credential Dataset of a
+  [token response](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-successful-token-response). It points to one Credential Dataset of a
   configuration.
 
 If the token response has `credential_identifiers`, the wallet uses `credential_identifier`.
@@ -2092,10 +2092,10 @@ Member `_issuance_configuration` of a credential configuration. It is not publis
 | Value | `iss` of the credential | Key found from | Needs | Status List url ends with |
 |---|---|---|---|---|
 | empty or `did:jwk`, the default | did:jwk of the signing key | the credential | nothing | `~did-jwk:<key thumbprint>` |
-| `did:web` | did:web of this deployment, from the issuer of the OP | `/.well-known/did.json`, header `kid` `did:web:…#<key name>` | **DID.Document** | `~did-web` |
-| `url` or the url itself | issuer of the OP | `x5c` when the key has certificates, otherwise `/.well-known/jwt-vc-issuer` | **OAuth.JWTVCIssuer** and the key in **shibboleth.oidc.SigningCredentialsToPublish**, when no `x5c` | `~url` |
+| `did:web` | did:web of this deployment, from the host of `idp.oidc.issuer` | `/.well-known/did.json`, header `kid` `did:web:…#<key name>` | **DID.Document** | `~did-web` |
+| `url` or the url itself | `idp.oidc.issuer` | `x5c` when the key has certificates, otherwise `/.well-known/jwt-vc-issuer` | **OAuth.JWTVCIssuer** and the key in **shibboleth.oidc.SigningCredentialsToPublish**, when no `x5c` | `~url` |
 
-The Status List Token of a credential names the same issuer as the credential.
+The Status List Token of a credential has the same issuer as the credential.
 
 ### Signing keys
 

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

More information about the commits mailing list