[Openid-dcp] DCP WG APAC 17th July 2025 Meeting Notes

[Stefan Charsley]

DCP WG APAC 17th July 2025
Attendees:

Christian Bormann

Martijn Haring

Daniel Fett

Craig Lambie

Kenichi Nakamura

Andres Olave

Joseph Heenan

Stefan Charsley

Updates:

   -

   Interop for VCI draft 16, good results, mailing list has been sent a
   preliminary report, no major issues identified with specs
   -

   Conformance tests have been updated, draft 16 for VCI, 1.0 final for VP


Discussing OpenID4VCI:

Presentation During Issuance #509
<https://github.com/openid/OpenID4VCI/pull/509>

   -

   Please review


Application Encryption Security Considerations #569
<https://github.com/openid/OpenID4VCI/pull/569>

   -

   Please review


Add "non-empty" to a few arrays added since the last pass #574
<https://github.com/openid/OpenID4VCI/pull/574>

   -

   Needs 1 more approval for merging
   -

   Approved by Stefan


bad indentation in credential metadata section #573
<https://github.com/openid/OpenID4VCI/issues/573>

   -

   Editorial, christian to take a look at it


Clarify what absence of scope from credential_configurations_supported
means #572 <https://github.com/openid/OpenID4VCI/issues/572>

   -

   Christian: 3.3.4 needs further clarification


add example for batch_credential_issuance #563
<https://github.com/openid/OpenID4VCI/issues/563>

   -

   Christian: also missing an example for signed metadata



Discussing HAIP:

remove any mandatory requirements for key attestations #188
<https://github.com/openid/oid4vc-haip/issues/188>

   -

   Martijn: shouldn’t mandate attestation format
   -

   Christian: would like to differentiate between different attestation
   types, agrees with Martijn when referring to key attestations, disagrees
   for client attestations
   -

   Martijn: would be great if there was a standardized format, but we
   shouldn’t be the group to create the standardized format, prefer to make
   recommendations. Existing formats should be supported, reissuing
   attestations for a certain mandated format introduces possible security or
   cost issues
   -

   Christian: the mental model for wallet attestation is the wallet
   provider backend is always attetesting, in EU its usually wallet provider
   responsibility from legal perspective
   -

   Martijn: agrees with almost everything, except there are scenarios where
   wallet provider backend doesn’t exist. If wallet provider backend is
   required, it should be made explicit in HAIP.
   -

   Christian: wallet attestations are used as a client authentication
   method. To allow other formats, you would need some sort of extension point
   for the client to use other formats. What about mandating wallet
   attestation, letting ecosystems choose what formats?
   -

   Martijn: what is the attestation attesting? What is the subject? Its not
   defined
   -

   Joseph: separate out wallet attestation and key attestation, rename
   issue to be specific about key attestation, create new issue #211 regarding
   wallet attestation. Sounds like consensus on having a recommended format
   but allowing other formats
   -

   Martijn: what does the recommendation mean? If you have no format use
   this one? If you have an existing format, there shouldn’t be a
   recommendation to switch/rewrap
   -

   Agreement of allowing existing attestations as is
   -

   Christian: vci metadata needs method for describing supported
   attestation formats


allow use of other wallet attestations formats? #211
<https://github.com/openid/oid4vc-haip/issues/211>

   -

   Martijn: downsides of mandating a wallet attestation format, subject
   that you are attesting is undefined, is it the wallet application itself?
   Is it the wallet provider? What if you don’t have a wallet provider backend?
   -

   Christian: problem with native attestations is how do you establish
   trust while maintaining privacy
   -

   Martijn: if this is mandatory in HAIP 1.0, you couldn’t change it
   without making a HAIP 2.0 as it wouldn’t be backwards compatible
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20250717/6e5ebe65/attachment-0001.htm>