[Openid-dcp] APAC DCP WG Call 20th Wed Call Notes

Thu Aug 21 02:44:27 UTC 2025

Issue 109

The decision of whether to use normative language or a non-normative note
referencing ISO 18013-5 for mDocs within the context of HAIP depends on the
specific goals and requirements for the HAIP standard.

Advantages of normative language for mDocs in HAIP

   - Mandatory Compliance: Normative language dictates requirements that
   must be followed for compliance with the HAIP standard. This ensures
   consistent implementation and interoperability across different HAIP
   systems.
   - Security and Trustworthiness: Given the sensitive nature of identity
   documents, including mDLs and potentially other mDocs, normative language
   helps establish a strong foundation for security and trust. ISO 18013-5
   itself emphasizes robust security and privacy features for mDLs.
   - Interoperability: HAIP may require mDocs to function seamlessly across
   various systems and jurisdictions. Normative language helps achieve this by
   setting a baseline for technical specifications and data structures.
   - Reduced Ambiguity: Normative language leaves little room for
   misinterpretation, which is critical in technical and legal documents.

Advantages of a non-normative note referencing ISO 18013-5

   - Flexibility and Adaptability: A non-normative note provides guidance
   without mandating strict adherence to a particular version of ISO 18013-5.
   This allows the HAIP standard to incorporate future updates or revisions of
   ISO 18013-5 without requiring a full revision of the HAIP document.
   - Avoid Redundancy: Directly incorporating the full technical
   specifications of ISO 18013-5 into the HAIP standard could create
   redundancy and potentially lead to inconsistencies if not carefully
   maintained. A non-normative note avoids this by pointing to the
   authoritative source.
   - Focus on HAIP-Specific Requirements: By referencing ISO 18013-5 in a
   non-normative note, the HAIP standard can concentrate on its specific
   requirements and functionalities related to mDocs, while relying on the
   external standard for foundational aspects of mDLs and mDocs.

The choice depends on the level of control desired

   - If the HAIP standard needs to explicitly dictate how mDocs are
   implemented and verified within the HAIP framework, using normative
   language is necessary. This would ensure the highest level of
   consistency and compliance with HAIP's specific needs.
   - If the HAIP standard aims to leverage the established framework of ISO
   18013-5 while maintaining flexibility for future adaptations, a
   non-normative note referencing the standard would be more appropriate. This
   approach acknowledges the importance of ISO 18013-5 without being overly
   prescriptive.

Ultimately, the decision should be guided by a careful assessment of the
potential benefits and drawbacks of each approach, considering the nature
and goals of the HAIP standard and the evolving landscape of digital
identity documents.

On Wed, Aug 20, 2025, 9:17 PM Tobias Looker via
Openid-specs-digital-credentials-protocols <
openid-specs-digital-credentials-protocols at lists.openid.net> wrote:

> # Attendees
>
>
>
> - Kristina
>
> - Martijn
>
> - Hicham
>
> - Ian
>
> - Lee
>
> - Brian
>
> - Danieal
>
> - Elizabeth
>
> - Mike
>
> - Peter
>
> - Raj
>
> - Rene
>
>
>
> # Events & Announcements
>
>
>
> - OpenID4VCI vote announcement has gone out, URL for this announcement is
> currently being fixed.
>
> - IIW dates have changed back to the 21st of October, DCP WG calls still
> plan to coincide with this.
>
>
>
> # Issues
>
>
>
> *## OpenID4VCI*
>
>
>
> - Martijn raised that issue 605 was merged with some agreed changes
> missing, either Gareth or Martijn will follow up with an additional PR to
> address.
>
> - Kristina created a new issue to track the required changes.
>
>
>
> *## HAIP*
>
>
>
> - 7 open PR's, reviews welcomed
>
> - All issues apart of the 1.0 milestone are now tagged as such
>
>
>
> - Issue 109, what should we say about ISO mDocs for status management
>
> **Lee** Why do we need to say anything?
>
> **Kristina** For interoperability
>
> **Lee** I think it should be out of scope of HAIP to concretely define
> this
>
> **Martijn** I also don't see why we need any normative language around
> this for mDocs in HAIP, could we instead point via a non-normative note to
> rev 2 of ISO 18013-5
>
> **Kristina** Im ok with that
>
> **Lee** Likewise provided it is non-normative
>
>
>
> - Issue 185
>
> **Kristina** The suggestion with this is to allow both HTTPs and data
> URI's but limit the content type to certain image formats such as SVG and
> PNG
>
> **Martijn** Just clarifying that the logo mechanism is not mandatory
>
> **Kristina** Thats correct
>
> **Lee** I think in the event this mechanism is used it makes sense to
> constrain the image formats supported.
>
> **Lee** Should we do this in VCI instead of HAIP
>
> **Kristina** Could be too restrictive, if we want MUST lets do it in HAIP
>
> **Tobias** I'll review text in both HAIP and VCI in relation to this
>
>
>
> - Issue 227
>
> **Martijn** It feels a bit strange to me to mandate a feature pre-auth
> that may come with additional security considerations
>
> **Paul** I feel somewhat similar
>
> **Lee** Pre-auth appears to be a pre-dominant pattern that many usecases
> require so if pre-auth isn't suitable in its current form we need to adapt
> the mechanism
>
> **Tobias** Lots of useful usecases are addressed with this I think we
> could constrain the usage to say using the DC API for transmission
>
> **Kristina** Lets put it into v1.1 when a DC API based mechanism for
> pre-auth should be defined.
>
>
>
> - Issue 104
>
> **Kristina** Any issues with mandating this based on the findings from
> FAPI
>
> **Brian** I don't believe there is much benefit in requiring it
>
> ***Lots of discussion, review recording***
>
> **Kristina** I will document and we can discuss with Joseph when he is
> back
>
> **Paul** Worth considering if we mandated this then we may not need PKCE
>
>
>
> - Issue 98
>
> **Tobias** With the current state of DC API this basically makes cross
> device flows impossible
>
> **Gareth** Understand this complication but the security considerations
> are real for cross device flows I don't think we should allow cross device
> using ordinary OpenID4VP
>
> **Paul** Agree with Gareth
>
>
>
> - Issue 236
>
> No objection to suggested change, Oliver is going to do a PR
>
>
>
> - Issue 237
>
> Briefly discussed, please review proposed changes in the issue
>
>
>
> Thanks,
>
> [image: MATTR website] <https://mattr.global/>
>
>
>
> *Tobias Looker*
>
> MATTR
>
> +64 273 780 461
> tobias.looker at mattr.global <first.last at mattr.global>
>
> [image: MATTR website] <https://mattr.global/>
>
> [image: MATTR on LinkedIn] <https://www.linkedin.com/company/mattrglobal>
>
> [image: MATTR on Twitter] <https://twitter.com/mattrglobal>
>
> [image: MATTR on Github] <https://github.com/mattrglobal>
>
>
> This communication, including any attachments, is confidential. If you are
> not the intended recipient, you should not read it – please contact me
> immediately, destroy it, and do not copy or use any part of this
> communication or disclose anything about it. Thank you. Please note that
> this communication does not designate an information system for the
> purposes of the Electronic Transactions Act 2002.
> --
> Openid-specs-digital-credentials-protocols mailing list
> Openid-specs-digital-credentials-protocols at lists.openid.net
>
> https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20250820/7389b80c/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 22001 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20250820/7389b80c/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 872 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20250820/7389b80c/attachment-0011.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 528 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20250820/7389b80c/attachment-0012.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 921 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20250820/7389b80c/attachment-0013.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 1045 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20250820/7389b80c/attachment-0014.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 921 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20250820/7389b80c/attachment-0015.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 1045 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20250820/7389b80c/attachment-0016.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 22001 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20250820/7389b80c/attachment-0017.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 872 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20250820/7389b80c/attachment-0018.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 528 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20250820/7389b80c/attachment-0019.png>