[java-idp-plugin-vci] branch main updated: improve readability of instructions

[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/1f3d57a246d7147a45cc5f726729a9fe12e382a4

The following commit(s) were added to refs/heads/main by this push:
     new 1f3d57a  improve readability of instructions
1f3d57a is described below

commit 1f3d57a246d7147a45cc5f726729a9fe12e382a4
Author: Janne Lauros <janne.lauros at csc.fi>
AuthorDate: Tue Sep 8 10:19:15 2026 +0300

    improve readability of instructions
---
 README.md | 15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/README.md b/README.md
index 0d876b2..0f1e995 100644
--- a/README.md
+++ b/README.md
@@ -349,11 +349,11 @@ different identity. You register both:
 
 The `/wallet` suffix is not a convention you may choose. A wallet that redeems a pre-authorized
 code does not authenticate, so the plugin resolves its client id by taking the client id of the
-creator of the offer and appending `/wallet` to it. Register that exact string or the token
-request has no relying party.
+creator of the offer and appending `/wallet` to it.
 
-*conf/relying-party.xml* then needs three relying parties. One for what a wallet reads before
-it has any identity at all, one for the caller and one for the wallet that redeems the code:
+*conf/relying-party.xml* then needs three relying parties. Unverified endpoints for mostly issuer
+related metadata publications, one for the party that creates the content for credential and one
+for the wallet that redeems the code:
 
 <details>
 <summary>Example snippet of conf/relying-party.xml</summary>
@@ -461,10 +461,9 @@ openid-credential-offer://?credential_offer={"credential_issuer":"https://issuer
 
 </details>
 
-The offer asks for both credentials at once and the wallet then requests them one by one with
-the same access token. Do not really do that. A wallet that is offered two credentials in one
-offer most likely fails miserably with it, so keep to one credential per offer. The two are
-here only to show where the formats differ.
+The offer in example asks for both credentials at once and the wallet then may pick one or the other. 
+Do not really do that. A wallet that is offered two credentials in one offer most likely fails miserably
+with it, so keep to one credential per offer. The two are here only to remind us it should be possible.
 
 Note that the paths are flat in both, also in the `vc+sd-jwt` one. The `credentialSubject`
 nesting of that format is done when the credential is built.

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