Skip to content

Conversation

@Sakurann
Copy link
Collaborator

resolves #214. resolves #37

  • changes the structure of proof_types from an array to a proofs_supported map that contains a required proof_signing_alg_values_supported parameter (required to avoid having an empty object...).
  • renamed cryptographic_suites_supported to credential_signing_alg_values_supported to clarify the purpose of the parameter.

Co-authored-by: Timo Glastra <timo@animo.id>
Copy link
Contributor

@decentralgabe decentralgabe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm!

@jogu
Copy link
Contributor

jogu commented Jan 29, 2024

I can't figure out how to make a suggestion but this text on line 713 needs to fixed as it still mentions proof_types:

The proof object is REQUIRED if the proof_types parameter is non-empty and present in the credential_configurations_supported parameter of the Issuer metadata for the requested Credential.

* `proof_types`: OPTIONAL. Array of case sensitive strings, each representing a `proof_type` that the Credential Issuer supports, as defined in (#credential_request), one of which MUST be used in the Credential Request. If this array is non-empty and present, the Credential Issuer requires proof of possession of the cryptographic key material. If the parameter is omitted or the array is empty, the Credential Issuer does not require proof of possession of the cryptographic key material.
* `cryptographic_binding_methods_supported`: OPTIONAL. Array of case sensitive strings that identify the representation of the cryptographic key material that the issued Credential is bound to, as defined in (#credential-binding). Support for keys in JWK format [@!RFC7517] is indicated by the value `jwk`. Support for keys expressed as a COSE Key object [@!RFC8152] (for example, used in [@!ISO.18013-5]) is indicated by the value `cose_key`. When the Cryptographic Binding Method is a DID, valid values are a `did:` prefix followed by a method-name using a syntax as defined in Section 3.1 of [@!DID-Core], but without a `:`and method-specific-id. For example, support for the DID method with a method-name "example" would be represented by `did:example`. Support for all DID methods listed in Section 13 of [@DID_Specification_Registries] is indicated by sending a DID without any method-name.
* `credential_signing_alg_values_supported`: OPTIONAL. Array of case sensitive strings that identify the algorithms that the Issuer uses to sign the issued Credential. Algorithm names used are determined by the Credential format and are defined in (#format_profiles).
* `proofs_supported`: OPTIONAL. Object that describes specifics of the key proof(s) that the Credential Issuer supports. This object contains a list of name/value pairs, where each name is a unique identifier of the supported proof type(s). Valid values are defined in (#proof_types), other values MAY be used. This identifier is also used by the Wallet in the Credential Request as defined in (#credential_request). The value in the name/value pair is an object that contains metadata about the key proof and contains the following parameters defined by this specification:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

proof_types_supported (here and in the examples) I think was the agreed on name from the call

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sorry if this is redundant w/ other comments/threads

@Sakurann Sakurann merged commit 3547e2d into main Feb 1, 2024
TakahikoKawasaki added a commit to authlete/oid4vci-demo that referenced this pull request Feb 2, 2024
…s_supported.json`

to `credential_signing_alg_values_supported` to align with the breaking change made by
openid/OpenID4VCI#235
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

9 participants