[Openid-dcp] Request for technical proposals ahead of joint meeting between ISO WG 10/DCP members

[Kristina Yasuda]

Hi Kenichi,

In my memory, jose-HPKE has been a preferred option since the first
discussions main reason being transition path from JWE with ECDH-ES (“HPKE
being another JWR alg without any breaking changes”) and because the rest
of the protocol is JSON. So it has nothing to do with SD-JWT VC.

vanilla HPKE was considered when IETF jose-HPKE draft progress was slower
than expected. Now jose-HPKE is in WG last call.

Also vanilla HPKE first needs to be defined in OpenID4VP, before anything
is mandated in HAIP. While jose-HPKE, we most likely can mention directly
in HAIP without adding anything additional to openid4vp.

Jfyi We added this note to OpenID4VP

> Note: For encryption, implementers have a variety of options available
through JOSE, including the use of Hybrid Public Key Encryption (HPKE) as
detailed in [I-D.ietf-jose-hpke-encrypt
<https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#I-D.ietf-jose-hpke-encrypt>
].

If you have any additional requirements around this other than mdoc/sd-jwt
vc compatibility (which is as I explained had not been a main decision
driver), that would be appreciated.

Thank you,

Kristina




On Wed, Dec 24, 2025 at 1:40 AM Nakamura Kenichi (中村 健一) <
nakamura.kenken at jp.panasonic.com> wrote:

>
> Hello Kristina,
>
> Yes, SD-JWT VC is not mandated in HAIP. However when I commented in DCP WG
> that I prefer Google proposal on HPKE, but it was opposed due to
> applicability to SD-JWT VC. It seems HAIP is not independent to credential
> format.
>
> Best regards,
> Kenken
>
> *差出人: *Kristina Yasuda <yasudakristina at gmail.com>
> *日付: *火曜日, 2025年12月23日 23:59
> *宛先: *Digital Credentials Protocols List <
> openid-specs-digital-credentials-protocols at lists.openid.net>
> *CC: *Nakamura Kenichi (中村 健一) <nakamura.kenken at jp.panasonic.com>
> *件名: *Re: [Openid-dcp] Request for technical proposals ahead of joint
> meeting between ISO WG 10/DCP members
>
> Hi Kenichi,
>
> > Current problem of OID4VP is that HAIP (1.0) is not desirable for
> ecosystems who do not use SD-JWT VC. OID4VP is a building block and may
> have profiles, the same as WG10 considers OpenID4VCI would have profiles
> and HAIP is one of them. I do not have an objection that DCP WG develops a
> profile for EU, but WG10 should specify a profile applicable for any mdocs.
>
> HAIP does not mandate SD-JWT VC and allows implementers to use it only
> with mdocs. could you elaborate why you believe HAIP does not work with
> "any mdocs"?
>
> Thank you,
> Kristina
>
>
> On Tue, Dec 23, 2025 at 2:40 PM Joseph Heenan via
> Openid-specs-digital-credentials-protocols <
> openid-specs-digital-credentials-protocols at lists.openid.net> wrote:
>
> (Resending, as it didn’t make it at least to the mailing list archive for
> some reason)
>
> Hi all
>
> Please see a proposal below as submitted by Kenichi.
>
> Thanks
>
> Joseph
>
> -------------------------
>
> For proximity use case, ISO/IEC 18013-5 device engagement already has
> capability info.
>
> DeviceEngagement =
> {
> 0: Version,
> 1: Security,
> ? 2: DeviceRetrievalMethods,
> ? 5: OriginInfos,
> ? 6: Capabilities,
> * uint => RFU,
> * nint => Ext
> }
>
> If wallet will indicate support of SD-JWT, protocol to retrieve SD-JWT VC
> can be used after session establishment. WG10 does not specify SD-JWT VC,
> so I don’t have strong opinion how to map request and response on the top
> of ISO/IEC 18013-5 session and DCP WG should do it because they are also
> considering support of SD-JWT VC. If DCP WG does not have expertise on it,
> WG10 can help it.
>
> For online use case, there is no way for wallet to inform its capability
> to relying party. But http get method already support  query which can be
> used to inform whether requester wishes to receive mdoc request or sd-jwt
> vc request.
>
> Current problem of OID4VP is that HAIP (1.0) is not desirable for
> ecosystems who do not use SD-JWT VC. OID4VP is a building block and may
> have profiles, the same as WG10 considers OpenID4VCI would have profiles
> and HAIP is one of them. I do not have an objection that DCP WG develops a
> profile for EU, but WG10 should specify a profile applicable for any mdocs.
>
> So I am not sure “harmonized protocol” is required or not and both parties
> should consider co-existence of two protocols.
>
> ————————————
>
>
> On 18 Dec 2025, at 18:42, Joseph Heenan <joseph at authlete.com> wrote:
>
> Hi all
>
> As was agreed in the first joint meeting, at the next meeting (on the 23rd
> December 13:00 – 14:00 UTC, the invite was sent to this mailing list
> earlier today) the group wanted to get into discussion about the form of
> the technical solution at the high level.
>
> After discussion between the ISO convenor & the DCP co-chairs we believe
> the best way to proceed would be if people could submit outlines of how
> they envisage the harmonised protocol looking. These outlines should be
> short, either concise text or a diagram, *definitely under 1 page.*
>
> The expectation would be that these high level proposals select various
> parts of the existing ISO 18013 / OID4VC protocols and combine them in a
> way that produces a "best of breed" solution.
>
> We’d encourage people that believe they might submit similar proposals to
> work together wherever possible to keep the number of proposals received to
> a minimum and hence use the meeting time in the most effective way.
>
> Please submit proposals ASAP (and prior to the 23rd Dec meeting) as a
> response to this message (with Loffie CCed so they can be distributed to
> ISO members too). We suggest we then quickly review the proposals at the
> meeting, and the group selects the least disliked proposal as a starting
> point that we then have detailed discussions about.
>
> Many thanks
>
> Joseph
>
>
> --
> 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/20251224/4d7d0698/attachment.htm>