In order to link source code to dokka html we use the following configuration

 sourceLink {
                localDirectory.set(projectDir.resolve("src"))
                remoteUrl.set(URL("${Meta.PROJ_BASE_URL}/tree/main/src"))
                remoteLineSuffix.set("#L")
            }

This, effectively, always point to the main branch, which clearly is not the case.
For instance, should we release v0.1.0 the source code urls must point under this release.

There should be a way to dynamically calculate the git ref for which which the dokka html is being produced.

Currently, project uses the Maven Publish gradle plugin, which in turn requires the use of Signing plugin.

There is an alternative plugin that seems to offer some advantages, compared to the standard plugin:

• Allows to declare POM attributes in gradle properties
• Streamlines the publication of SNAPSHOT & releases in the basis of the version name
• Makes the build script much cleaner
• Most importantly, allow to fully automate the handling of the Maven Staging repo

To adapt this:

• Externalize to gradle.properties the meta-data of the project
• Define the publication scope in terms of the new plugin (removing the maven-publish and sign plugins)
• Change the ci.yaml to use the new plugin for SNAPSHOT deployments
• Change the release.yaml to use the new release deployment

Presentation Exchange contains a section about the contents of an attribute named format which can be found either as a top-level element of presentation definition or with an input_descriptor.

This format is a JSON object having as attribute names claim formats coming by a controlled registry. In turn, each of these nested claim formats may point to another JSON Object which contains either an array alg or proof_type as defined in the relevant json schema.

Library reflects in its types the above rules, strictly. There are problems with this strictness:

OpenId4VP draft 20 uses claim formats that are not (yet) registered to the aforementioned Presentation Exchange controlled registry. In particular:

• jwt_vc_json & jwt_vp_json in A.1.1
• ac_vc & ac_vp in A.2
• mso_mdoc in A.3
• sd+jwt-vc to be added for sd-jwt-vc (PR). This doesn't only add a new value but redefines the contents of the relevant JSON to contain two arrays : sd-jwt_alg_values & kb-jwt_alg_values

So library-wise there are two options:

• Implement just the registered claims formats (current approach)
• Relax the format object accepting the fact that neither all keys are registered nor the contents of their value

The first is too restrictive, I guess. Perhaps we should go with the 2nd option.

As highlighted in eu-digital-identity-wallet/eudi-lib-jvm-siop-openid4vp-kt#217 there is a need to make the model classes to implement java.io.Serializable

JwtAlgorithm.DigSig is defined as an enumeration. This limits the possible values that can be used and requires code changes to introduce support for new algorightms.

Given for instance no constants exist for ESB256, ESB320, ESB384, and ESB512, the following format fails to parse:

{
  "format": {
    "mso_mdoc": {
      "alg": [
        "ES256",
        "ES384",
        "ES512",
        "EdDSA",
        "ESB256",
        "ESB320",
        "ESB384",
        "ESB512"
      ]
    }
  }
}

We must consider converting JwtAlgorithm.DigSig (or JwtAlgorithm) to a value class.