1.

The OpenID4VP document needs to be finalized, approved, and published.

OIDF

OIA_03

7.

The HAIP document needs to be finalized, approved, and published.

OIDF

9.

The OpenID4VCI document needs to be finalized, approved, and published.

OIDF

ISSU_01

2.

It should be verified whether OpenID4VP (via the Presentation Exchange specification referenced therein) allows a Relying Party to group the attributes they request based on the use case, service, or purpose. If this is not the case, a method for doing so needs to be specified.

Comment: The idea of grouping the attributes in the request means that the RP can indicate a goal or purpose per group, and the user can decide to release or not release the attributes per group. This prevents situations where a user refuse consent for one attribute and releases others, while the RP needs all of them to proceed. That would be bad for privacy or user experience. In fact, partly as a result of this requirement, ISO is going to implement this in Amd 1 of 18013-5.

OIDF

RBA_11^[1]

3.

…. A question, therefore, is whether to allow the transport of ISO-compliant attestations (mdocs) using OpenID4VP, or wants to simplify the situation by requiring that ISO-compliant attestation shall be requested and presented only using the protocol defined in ISO/IEC 18013-7 Annex A (REST API): …

TBD

4.

A question to be clarified is the relationship between OpenID4VP, ISO/IEC 18013-7 and the W3C browser API. W3C has founded a Federation Identity Working Group that will lead this work. It is understood that the standard will be reflected in an ISO/IEC standard, but this should be verified with W3C.

Note that there is a larger discussion where to define how to use OpenID4VP digital credentials API with mso_mdoc: OpenID4VP or ISO. ISO seems to be preferring that to be done in OpenID4VP, but there is no conclusion yet; This will be discussed with both ISO and OIDF.

TBD

5.

OpenID4VP must specify two mechanisms allowing revocation of attestations: Attestation Status List and Attestation Revocation List, as defined in Annex 1 of the ARF. This is already proposed for Amendment 1 of ISO/IEC 18013-5.

Notes:

· The Attestation Status List mechanism is specified in the Token Status List draft RFC, https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/ .

· A proposal for an Attestation Revocation List can be found on GitHub, https://c2bo.github.io/draft-bormann-identifier-list/draft-bormann-identifier-list.html

· The High-Assurance Interoperability Profile states that revocation is in scope, but it doesn't contain any requirements, although it references an older version of the Token Status List draft RFC.

OIDF

VCR_09

6.

OpenID4VP must enable a Wallet Instance to transfer a proof of association to a Relying Party,

in case multiple attestations are presented in the same response.

OIDF

ACP_09

1.

A few details must be added or adapted to ensure the protocol specified in OpenID4VCI is fully fit

for the purpose of attestation issuance within the EUDI Wallet ecosystem, especially to allow the use of key association as defined in ARF Annex 2 Topic 9. More details can be found in section 7.3 of “Epic 09 - Wallet Trust Evidence”, v1.0, NiScy, 2024-03-05.

OIDF

WTE_23 WTE_25

WTE_26

WTE_27

1.

The OpenID4VCI protocol must allow the Attestation Provider to send an embedded disclosure policy for the attestation to the Wallet Instance, where the policy is expressed in accordance with section Error! Reference source not found..

Note: It may be that this will not necessarily require a protocol change in VCI, as either the Provider includes the policy in the issued attestation or issues policy as an attestation. To be discussed with OIDF.

OIDF

EDP_08

1.

The HAIP includes a section profiling OpenID4VP. This profile is generic and hence also applies when OpenID4VP is used to request and present SD-JWT VC-compliant attestations, in contrast to the profile in ISO/IEC 18013-7. However, the HAIP profile for OpenID4VP contains far fewer details compared to the profile defined in ISO/IEC 18013-7, which raises questions on its completeness. OpenID Foundation should be asked to reflect on this and to create a profile that specifies all relevant details and is complete enough to guarantee interoperability. Topics include at least

· Defining cryptographic cipher suite(s), i.e., cryptographic algorithms mandatory to be supported by EUDI Wallet Instances and Relying Party Instances.

· Supporting Relying Party authentication in compliance with relevant requirements in ARF Appendix 2 and the Common Access CA Certificate Policy (section Error! Reference source not found.).

OIDF

RPA_01

RPA_02