In file RequestIssuanceImpl

we should add the following

         ProofBuilder.ofType(ProofType.JWT) {
            iss(config.clientId)
            aud(issuerMetadata.credentialIssuerIdentifier.toString())
            publicKey(proofSigner.getBindingKey())
            credentialSpec(credentialSupported)
            nonce(cNonce.value)
            build(proofSigner)
        }

That is to add the issuer claim

• Support the alternative way of specifying credential to be issued in terms of credential_identifier
• Handle attribute 'notification_id' when parsing the credential response.
• Attribute 'format' removed from issuance response.

An author of Ktor advised me that Ktor 2.3.6 onwards, ktor client user Dispatchers.IO
Check here

So far the library tries to match the issuer's requirements for the encryption of the response (that carries the issued credential).
In general VCI allows the issuer to chose one of the following options:

• Not Used (credential_response_encryption is not provided to issuer's metadata)
• Supported but not required (credential_response_encryption is present and encryption_required is false)
• Required (credential_response_encryption is present and encryption_required is true)

Wallet could also define a similar policy independently of the issuer's choice. During resolution of a credential offer there could be a step to assure that those two policies are compatible and proceed with the issuance.

The wallet's policy can be the following:

• Required
• Supported

Parameter resource parameter should be included in the authorization request when issuer's metadata specify a different authorization server that protects issuer's endpoints. Parameter property must be set to the Credential Issuer's identifier.

From spec (section 5.1.2):
"If the Credential Issuer metadata contains an authorization_servers property, it is RECOMMENDED to use a resource parameter [RFC8707] whose value is the Credential Issuer's identifier value to allow the AS to differentiate Credential Issuers."

Currently our example assumes that the a wallet knows somehow

• A CredentialIssuerId
• The scope(s) that correspond to every credential that can be issued.

With that at hand, we obtain the metadata and then query them to locate the CredentialId that we are interested in.

We can improve this by

• assuming that the wallet has a CredentialOffer (with grant = authorization code)
• Even better, should we add to the PID issuer the ability to make CredentialOffer we can bring in to the example and effectively test our CredentialOfferResolver

By the way, in future the result of resoliving an offer could be the creation of an Issuer instance

Currently library does not support integration with issuer's Batch Credential Endpoint (section-8).
Api must be extended in a way that allows the caller to submit Batch Credential Requests

Simplify lib functinality to be format agnostic.

HTTP clients for OAUTH2 & Credential Issuer use transfer objects - representing requests / responses.
Some of those transfer objects are in .internal.format package whereas others are in .internal

We need to improve this and in particular put all related transfer object into the same package

Attribute supported_credentials has been change from a list of credential metadata, to map where each entry is a key (a unique identifier for the specific credential) and the value is an object with the credential metadata

OpenId4VCI (draft 13) foresees the use of optional parameter user_hint in the credential request.

user_hint: OPTIONAL. JSON String containing an opaque user hint the Wallet MAY use in subsequent callbacks to optimize the user's experience. This is RECOMMENDED in Dynamic Credential Requests
here

Do we need to support this?

Added a new attribute named authorization_details

Currently library does not support integration with issuer's Deferred Credential Endpoint (section-9).
Api must be extended in a way that allows the caller to submit Deferred Credential Requests passing the transaction_id returned from issuer as response to the initial credential issuance request

ProofBuilder and in particulat the JwtProofBuilder currently verifies - using issuer metadata - that the issuer support JWT proof.

In draft 13, a new mandatory attribute was added to issuer metadata, named proof_signing_alg_values_supported which is defined as

proof_signing_alg_values_supported: REQUIRED. Array of case sensitive strings that identify the algorithms that the Issuer supports for this proof type. The Wallet uses one of them to sign the proof.

This information can be used that wallet provides a ProofSigner that supports the issuer defined algorithms

Credential offer parameters

• Changed the definition of credentials parameter. Now, it is only an array of string
• grantsChanged to optional. If not provided, Wallet must take the flows supported from OAuth2 server metadata.
• Also, the contents of Grant Types has been changed. In both case a new option field named authorization_server has been added

Draft 13 clarified the meaning of encryption_required especially in case is set to false.

Currently, our library checks that when this flag is set to false, issuer should not define encryption methods.

Draft 13 clarifies that this is not the case. When setting false the flag it is ok to have encryption methods and it is up to the wallet whether it will request for an encrypted response or not.

In this case, it would be nice to change our code to request encryption from the issuer or add a configuration option

Example must be updated to also test the issuance of mDL.

Depends on eu-digital-identity-wallet/eudi-srv-pid-issuer#79 being merged

The new version of the sonar cloud gradle plugin that we use to perform the analysis, gives the following warning

The 'sonarqube' task depends on compile tasks. This behavior is now deprecated and will be removed in version 5.x. To avoid implicit compilation, set property 'sonar.gradle.skipCompile' to 'true' and make sure your project is compiled, before analysis has started.
The 'sonar' task depends on compile tasks. This behavior is now deprecated and will be removed in version 5.x. To avoid implicit compilation, set property 'sonar.gradle.skipCompile' to 'true' and make sure your project is compiled, before analysis has started.
Kotlin DSL property assignment is an incubating feature.

I think that this means that we should check again our github action.

BTW, the message can be reproduced by invoking any gradle operation

Credentials Offer

credentials parameter

Changed the definition of credentials parameter.
Now, it is only an array of string

grants.

Changed to optional. If not provided, Wallet must take the flows supported from OAuth2 server metadata.
Also, the contents of Grant Types has been changed. In both case a new option field named authorization_server has been added

Note It is not clear to me the omission of grants. OAuth2 server metadata don't have a placeholder for pre-authorized_code

Token response

Added a new attribute named authorization_details
Fortunately, it is required in authorization_details have been used

Credential Request

Added a new field credential_identifier. It is required only in case that authorization_details have been used.

Credential Issuer Metadata Parameters

• Added multiple authorization_servers
• Added proof_types_supported

Refresh credential

New feature, using refresh_token

Derived issues:

• #65
• #66
• #67
• #76

It seems that there are two DID methods we can support with minimal effort.

Those methods are

1. did:jwk
2. did:key

Both methods use the following approach:

Given that you have a key pair, you can produce a did by serializing into a string the public key (serialization is different between the two methods) and the prepend the appropriate appropriate did:jwk: or did:key: to form a did (and a did url).

A party that receives such a did given that the pub key is trusted, it can map it to a predefined did document (different for each method).

So, given that our Proof builder already supports jwk claim we can expanded to support kid ( addressed in #42 )

Add support to request issuance of credentials of W3C signed jwt (not using JSON-LD) profile (Appendix A.1.1)

Readme examples are not valid after refactoring

credential_identifiers property of authorization_details in a token response should be optional

ref: https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#section-6.2-4.3.2.1

The contents of a credential offer has been changed in the pre-authorized code case.

A new attribute tx_code replaces user_pin and some more new metadata were added

Dear team,

State is currently generated inside AuthorizeIssuanceImpl and can not be extracted or stored after calling AuthorizeIssuance.prepareAuthorizationRequest() without parsing resulting authorizationCodeURL

At the end of the flow Wallet instance will get the code and state
(e.g. "state=umerLYauAS-E33UK64uD3SMoC2orCslWku9xSrGm5Rc&code=blDtU1XSgFyMv1FoBg6402GRaXHsDZ8JgKgzVR-Sv-E")
At this point Wallet instance MUST parse this url to get the code to continue the flow by calling authorizeWithAuthorizationCode on a persisted AuthorizationRequestPrepared object. At this point Wallet needs to be sure this persisted object matches the original state.

I see several solutions:

• Provide generated state as a parameter to (AuthorizeIssuance.prepareAuthorizationRequest(state))
• Return pair of state and AuthorizationRequestPrepared object as the result of a successful authorization
• Add state to AuthorizationRequestPrepared object
• do nothing and just parse authorizationCodeURL

All these solutions will help Wallets, to restore their state (AuthorizationRequestPrepared) by a state value and continue the flow.

Your thoughts?

Gennadi

In the case of pre-authorization code flow, when request for token is posted the grant_type value is URL encoded when it should not.

Changes

• #168
• Add credential_response_encryption. These should include alg_values_supported , enc_values_supported and encryption_required which were used to be top-level items
• New attribute credential_identifiers_supported added
• Renamed to credential_configurations_supported
• Add an additional value to proof_types_supported ldp_vp

Check the cryptographicSuitesSupported constraint of the JwtProofBuilder

Is it relevant. In draft 13 attibute has been removed

checkNotNull(claimsSet.claims["nonce"]) {
                "Claim 'nonce' is missing"
            }
            if (!credentialSpec!!.cryptographicSuitesSupported.contains(algorithm.name)) {
                throw CredentialIssuanceError.ProofGenerationError.CryptographicSuiteNotSupported
            }
            if (!credentialSpec!!.proofTypesSupported.contains(ProofType.JWT)) {
                throw CredentialIssuanceError.ProofGenerationError.ProofTypeNotSupported
            }

Draft 13 added a new optional endpoint to the issuer, that allows a wallet to send notifications (call backs) after issuance.

Perhaps this functionality could be included to the library.

RFC9449 defines DPoP JWT as a way to:

• Ensure that an issued access_token is used by the client (wallet) that requested it, and
• Constraint the usage of the access_token

This DPoP (demonstration of Proof of Possession) must not be confused with Proof Of Possession that may be used within the credential request.

The basic requirement is:

Token Request

• Lib can place a request against the Token Endpoint (to obtain access_token) adding as an HTTP header a specially prepared DPoP JWT. htm and htu should point to token endpoint method and URL (no fragment, no query)
• In case OAUTH2 server supports DPoP, it will reply with
  • token_type equal to DPoP, otherwise
  • bearer
• Library should store this information (whether DPoP was supported)

Placing a call to Issuer Endpoints
For accessing one of the endpoints of the issuer (that require access_token: issuance, batch, deferred, notification) , library must

• generate a new DPoP JWT . htm and htu point to the method and endpoint used
• add the DPoP as an HTTP header
• Change the way access token is placed as a header. Instead of Authorization bearer <access_token> to `Authorization DPoP <access_token>'

When instantiating Issuer using a deep link representing a credential offer, caller has no access to the resolved credential offer.

A solution would be to make the resolved credential offer accessible from the Issuer

From spec (section 4.1.1 ):
"user_pin_required: OPTIONAL. Boolean value specifying whether the AS expects presentation of a user PIN along with the Token Request in a Pre-Authorized Code Flow. Default is false. This PIN is intended to bind the Pre-Authorized Code to a certain transaction to prevent replay of this code by an attacker that, for example, scanned the QR code while standing behind the legitimate user. It is RECOMMENDED to send a PIN via a separate channel. If the Wallet decides to use the Pre-Authorized Code Flow, a PIN value MUST be sent in the user_pin parameter with the respective Token Request"

Currently the library does not enforce the provision of a pin code when authorizing an issuance request if credential offer grant type is pre-authorized_code and property "user_pin_required" is present and its value is true.

DispatchOutcome.VerifierResponse.Rejected must be updated to a data class that contains an nullable property redirectUri similar to DispatchOutcome.VerifierResponse.Accepted.

Even in the case that the user didn't give his consensus to present a credential, the verifier might want to be redirect to a certain uri to display extra information to the user.

According to draft 19

CredentialMetada must contain an array of authorization_servers

Hi.

Specification says we should add (conditionally) Location to AuthorizationDetails which is missing now.
https://github.com/eu-digital-identity-wallet/eudi-lib-jvm-openid4vci-kt/blob/main/src/main/kotlin/eu/europa/ec/eudi/openid4vci/internal/AuthorizationServerClient.kt#L365

If the Credential Issuer metadata contains an authorization_servers parameter, 
the authorization detail's locations common data field MUST be set to the Credential 
Issuer Identifier value.

ref: https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#section-5.1.1

CryptographicBindingMethod should have an additional member

data object X5C: CryptographicBindingMethod {
        private fun readResolve(): Any = X5C

    }

• The client id is missing. Should be set from config
• Claim name PRE_AUTHORIZED_CODE_PARAM is wrong.

const val PRE_AUTHORIZED_CODE_PARAM = "pre-authorized_code"

expires_in should be nullable

ref: https://www.rfc-editor.org/rfc/rfc6749.html#section-4.2.2

In current implementation of the library authorization of an issuance request is based on the existence of a scope attribute of a credential configuration in issuer's metadata. In case the attribute is missing authorization requests do not include these credentials.

This behavior should be changed as follows:

• In case credential configuration includes a scope attribute for the credential use it.
• In case credential configuration does not include a scope attribute create the respective authorization_detail element and include it in the authorization request.

Thus the resulting authorization requests can include both scopes and authorization details attibutes.

• #147

Currently, JwtProofBuilder supports jwk claim.
We could extended to support, also

• kid claim
• x5c claim

To do so, perhaps some of the checks about compatibility of JWK & Signing Alg need to be removed

With draft 13, when requesting credential issuer meta-data you can pass one or more languages
via Accept-Language header parameter.

Issuer can use this value to adjust the display information of the supported credential configurations.

So, probably makes sense to add a set of supported languages to the issuer configuration

We should pass tx_code instead of user_pin

• Support authorization_details including credential_identifiers

• We need to check all data classes that are serialized with kotlinx.serializaiton JSON. Optional(nullable) attributes, must have always a default value, otherwise during decode we receive an error.
• Also when calling Json.decode() function we should use a decoder that ignores unknown values.

An example of this problem is the following

@Serializable
data class CredentialDefinitionTO(
  @SerialName("type") val type: String,
  @SerialName("claims") val claims: Map<String, ClaimTO>?,
)

The claims attribute should have a default value either null or non empty map