[Openid-specs-digital-credentials-protocols] meeting notes 2024-12-17

[Tim Cappalli]

# DCP Working Group 2024-12-17

## Attendees

- Kristina
- Tim Cappalli
- Steve Venema
- Lee Campbell
- David Zeuthen
- Brian Campbell
- Hicham Lozi
- Ryan Galluzzo
- Daniel Fett
- Christian Bormann
- Paul Bastian
- Andrew Regenscheid
- Bjorn Hjelm
- Lukasz Jaromin
- Victor Lu
- Nemanja
- Joseph Heenan
- John Bradley

## Administrivia

- vote for OID4VP ID3. https://openid.net/foundation/members/polls/346
- schedule: Thursday (19) call is the last call of 2024. First 2025 call is
2025-01-07.
- Hybrid meeting @ OSW (Tuesday before), no registration link yet.
- Steve: Is the appendix of (?) duplicative?
- Joseph: VP is defining framework, HAIP is telling you how to use that
framework interopable
- Paul: HAIP is just narrowing down options
- Lee: Nothing in HAIP should be new, just referencing bits

## 2025 Budget and Goals

- Kristina reviews the planned schedule for 2025 (documented in agenda)
- Lee: like the idea of the test events, need to put call out early. Need
to get early Jan if doing feb, more time if doing IIW
- Joseph: IIW is too late for 1.0 feedback
- Kristina: then need to do Feb 25. More details in Jan

>From chat:

- MOSIP Connect is 3/10 in Manila. TBC who from OIDF staff would lead, but
they have a desire to propose a conformance process to countries including
OIDF4VC test suites
- DICE is March 4/5 in Zurich, with a Unconference model, cohosted by
Kaliya.

- David Z: might be an ISO test event the same day
- Kristina: 4th
- Lee: why don't we test OpenID4VP at the ISO test event?
- Hicham: if it's ready, will be included
- Gail: Same time as STA event?
- David Z: will get back with dates

Add comments:
https://docs.google.com/document/d/137R2qJmsTHlalXUMV8W6kEQSTaFAMga6HFpu7vY1KlE/edit?tab=t.0

## Conformance Tests

- Kristina: have verifier tests now, used with Funke
- Gathering more requirements
- DC API is listed, as well as DCQL
- Next is VCI
- Joseph can help on the tests or if you have feedback

## Spec Work

- 276: thanks for all the work
- Can we start implementer's draft for OpenID4VCI?
- Realistically 45 day review would start post-12/24
- Second ID should come before the end of February
- Any objections? None
- Chairs will send out WGLC email by tomorrow
- Discussion around process and timelines, no action

## HAIP

- 122: ready for merge, will be merged after pipeline issues
- 135: session transcript for DC API
- question around hashing nonce, clientId, and origin due to other parties
being in the flow
- David Z: makes sense to hash it, ex: cloud HSM, might need to send the
whole thing, more privacy
- Paul: agree, same as for normal OID4VP
- Lee: weren't we going to put it in the base spec and have it be generic
for all credential formats?
- David Z: mdoc to create the mdoc specific device response.
- Lee: it was the AAD
- Kristina: last week made decision to put session encryption over DC API
in the base spec, and specific algos in HAIP
- Joseph: SD-JWT KB defined in VP, maybe handover should be there too?
- Lee: Think VP is a better place
- Paul: agreed
- Objections?
- Hicham: what about origin in the API vs here?
- Kristina: origin comes from platform, client ID comes from verifier
- John: client ID may be operating from different origins. Trust mark is
over the client ID.
- Joseph: multiple client IDs on same origin
- Hicham: there may be cases where audience should be restricted
- John: running a verifier as a service, origin and client ID will be
different
- Brian: re: SD-JWT, right now there's onyl the facility to include the
client ID, based on audience. Is there a need to diverge for mdoc?
- Lee: each thing has a reason: nonce for replay, origin for mitm protection
- John: if signed, no need for platform
- Lee: yes, you do, sign origin into response
- Lee: need to be able to tell where it comes from
- Joseph: unsigned, already passing it in the client ID parameter
- Lee: need to have expected origins
- Tobias: why wouldn't we universally opt to trust the origin from the
platform in both cases. more consistent.
- Paul: suggest adding origin to KB JWT then?
- Tobias: yes
- Tim: RP ID in WebAuthn is similar to client ID and origin is the same.
Matching origin to client ID is server side.
- Lee: Doesn't hurt to sign it
- Tobias: agree, most robust way forward
- Hicham: agree that client ID is controlled by verifier,even if you have
multiple client IDs per origin, verifier will still verify. owner of origin
controls the signature, doesn't provide more value.
- John: to route it back to the appropriate party is important
- Brian: No downside to signing the origin, just potentially divergence
from other credential formats
- Kristina: whatever we do here would affect KB JWT as well. When the
request is signed, put cliet ID as audience, when unsigned, use platform
provided origin as the client ID and put it in the response. Why is this
not sufficient?
- Daniel: makes sense to add it here and to KB JWT.
- Paul: agree. fine for OID4VP to define parmaeter for KB JWT. unique to DC
API not for other transports.
- Joseph: need to be careful about defining overlapping behaviors for
signed requests. Bit weird to have verifier also verify if wallet is.
- Kristina: might be an argument to not have origin in KB JWT
- Joseph: for signed requests, you don't get any value from the verifier
for origin. no value in verifier checking the origin.
- Tobias: Still need to trust the wallet did that. Wallet is more likely to
skip the check. Verifier wants to know the response is for them. Wallet may
just want requests to suggest. More robust check.
- Joseph: veriifer still needs to trust the wallet, wallet could just
change origin. verifiers skip checks all the time
- Tobias: maybe an argument for no expected origins, so it can't be skipped
- Lee: expected origins still gives you the MITM attacker not getting
anything. I think Joseph is right in that for a signed request the verifier
origin check is somewhat redundant if everything is working correctly. So
really is just a question of consistancy between keeping the structure the
same between signed and unisgned requests
- Tobias: clarify Lee's comment, it is redunant under teh assumption the
wallet has done what its supposed to do. Still useful server side, but
understand it is redundant. In signed request, allows wallet to fail faster.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20241217/f88bdcb6/attachment-0001.htm>