[Openid-specs-digital-credentials-protocols] DCP WG + SIOP Call (APAC) - 18-MAR-2025 - Minutes

Sun Mar 23 18:59:43 UTC 2025

Date: 18-MAR-2025

Attendees:

   - Torsten Lodderstedt (TL) - co-chair
   - Kristina Yasuda (KY) - co-chair
   - Gail Hodges (GH)
   - Alan Wang
   - Andres Olive
   - Bjorn Hjelm
   - Christian Borman (CB)
   - Daniel Fett (DF)
   - David Zeuthen (DZ)
   - Gareth Oliver
   - Hicham Lozi (HL)
   - Ketan Mehta
   - Lee Campbell (LC)
   - Lukasz Jaromin
   - Martijn Haring
   - Mirko Molik (MM)
   - Oliver Terbu (OT)
   - Paul Bastian
   - Peter Sorotokin
   - Ryan Galuzzo (RG)
   - Timo Galastra
   - Dima Postnikov (minutes)

—————————————————————————————————————

# Anti Trust Policy
OIDF Antitrust Policy at www.openid.net/antitrust applies / IPR reminder

—————————————————————————————————————

# Events and polls

Implementers' draft voting for HAIP has started. PLEASE VOTE:
https://openid.net/foundation/members/polls/355

Please register for DCP workshops: Sign up for the DCP WG event on 4/7
ASAP:
https://openid.net/attend-the-oidf-workshop-prior-to-iiw-spring-2025-on-7th-april-2025/

Interop events

GH will send an email during this call for the small group interop
participants to confirm (Y/N) their ability to attend each interop event
targeted for 3/27, 4/4, 4/25, and then the public event for 5/5.

—————————————————————————————————————

# Issues and PRs

VC Issue 400 Verifier's public key in sessionTranscript
https://github.com/openid/OpenID4VP/issues/400

TL: introduced the issue

HL: suggested this to be used for signed request objects, too

CB: Benefit for unsigned variant.

LC: This makes the attack detectable.

OT: Is Supportive. When will we tackle it for SD-JWT

LC: Set of things has to be signed over. It’s awkward to do it per format.

TL: I am hesitant to define the structure for all formats because they
differ. However, I am supportive of defining common security considerations.

LC: Agreed

KY: It’s already written this way. For example, the audience and Nonce have
to be present. The suggestion is to start adding it for mDocs first. Other
formats can be done later.

CB::
https://openid.github.io/OpenID4VP/openid-4-verifiable-presentations-wg-draft.html#section-14.1

“This specification assumes that a Verifiable Credential is always
presented with a cryptographic proof of possession, which can be a
Verifiable Presentation. The Wallet MUST bind this cryptographic proof of
possession to the intended audience (the Client Identifier of the Verifier)
and the respective transaction (identified by the nonce parameter in the
Authorization Request). The Verifier MUST verify this binding.”

LC: Agreed

OT: You can assign the issue to me. SessionTranscript will include a
thumbprint of x.509 key.

TL: Marked as ready for PR

—————————————————————————————————————

KY: Still waiting for Lee’s PR on VCI and DC API

LC: The PR is stable now

—————————————————————————————————————

VP Issue 6: VCs without VPs: https://github.com/openid/OpenID4VP/issues/6

Potential breaking change

DF introduced the issue: Key binding is not always required

Use cases:

   - Credentials don’t need to be bound to a specific key
   - Claim based binding
   - There is an example in the issue: you present a credential without
   claiming to be the credential owner.

TL: VCI talks about claims-based binding but doesn’t enable

CB: An essential feature

PB: My text is in the issue - we need to allow this

LC: Why can’t every credential have a key? It doesn’t have to be
hardware-bound. If they don’t have a key, it’s not an issued credential

DZ: Disagreed with LC. It might be misleading. Movie Ticket credentials
wouldn't need keybinding...

LC: Passkeys ecosystem is built on it

DZ: It seems reasonable to always require the key

PB: There are many examples where key binding is not required. It’s a nice
key to have. Passkeys can’t be used as a valid comparison.

LC: Key binding proves possession of the key but is also used for binding
the session.

DF: What Paul said. Introducing the key and not caring where it’s stored
can create security problems.

LC: Credential (with a key) vs signed statement (no key). Openid4vp is not
required for the second scenario.

TL: Scenario: same tx with two credentials (PID + education statement)

LC: It makes sense if you derive security properties from one of the
credentials, but it seems weird.

DZ: It might be nice not to give up the replay protection.

PB: I think we make backup and recovery a lot easier for many credentials

You gain all the other benefits for the user of the Wallet instead of
having a URL

RG: It certainly seems like there are realistic use cases to support this.
But to Lee’s point, there needs to be a very clear indication of what
threats are introduced when it comes to the unbound “credentials

TL: It's not a good idea to discard this issue. Move on and further
elaborate on the issue. Talk about additional threats, as RG suggested.

DF: I have a feeling this is what we have done already.

TL: It seems that the use cases are not clear to everybody. Please let me
know if you have a different suggestion.

MM: Delegation might be a use case for this scenario.

PB: I’ve presented this twice already, and people always saw the potential
for claim-based credentials.

TL: The question is whether every credential presented via openID4vp has to
be key-bound. Clarity needs to be added.

DF: Yes, but it won’t have the same security properties

SC: What about using a shared secret, but the secret is public? e.g., jwk
in SD-JWT cnf claim. Then, keybinding can occur but can be effectively
disregarded.

OT: I believe there is some language that says key binding is required

RG: Draft 24 still has Claim-based holder binding in the terminology
section, which certainly implies that the spec had planned to support or at
least discuss it at some point, which it currently does not outside of its
own definition.

DZ: The way my team and I read VCI and VP—and I'm not saying we read it
correctly:-)—is that they support keyless credentials. Our multiple
projects support this with a Movie Ticket credential in SD-JWT VC shape for
issuance and presentation. It's trivial to make them key-bound.

CB: VCI can be implemented without key binding right now, but VP is a bit
funky

OT This specification assumes that a Verifiable Credential is always
presented with a cryptographic proof of possession,n which can be a
Verifiable Presentation. This cryptographic proof of possession MUST be
bound by the Wallet to the intended audience (the Client Identifier of the
Verifier) and the respective transaction (identified by the nonce parameter
in the Authorization Request). The Verifier MUST verify this binding.

This security consideration would need to be updated.

RG: Even if we do that, we need to discuss the security properties' changes.

TL to DF: let’s come up with the proposal

—————————————————————————————————————

RP registration certificates and other attestations/certificates to match
issuer policies: https://github.com/openid/OpenID4VP/issues/396

MM: introduced the issue and EUDIW requirements.

A centralized registry might not be required, but JWS might be okay.

VP request can be extended to attach a credential about themselves

The idea is to make it generic so it can be used for other things.

CB: on a normative side, we are defining new parameters. Would this be an
optional extension, e.g., “ecosystems can add additional request parameter”

TL: It would be a meta-extension point for different purposes.

OT: Asked for clarification

MM: RP attests that they are a German organization to the Wallet. Defining
a query language within x.509 is not a good idea. x.509 is used for
authentication but for intended use or disclosure policy; these will be
attached to the request

OT: These are not key bound. How do you ensure binding?

MM: Bound to the DN. Claim bound, not key bound.

TL: Most of our work is based on challenge responses. Additional
credentials might or might not be key-bound, e.g., used for
authorization, and can be issued by other parties.

OT: If they are not replay-protected, how do we protect against certain
attacks? This needs to be defined.

TL: Do you know if it is a useful extension?

DP: Seems helpful to me

CB: It makes sense, but how it’s done is unclear.

TL: Let's go ahead and present it on Thursday again.

—————————————————————————————————————

Planned but not discussed:

   - please review! as this one unblocks some other important PRs:
   https://github.com/openid/OpenID4VP/pull/448
   - broaden transaction data https://github.com/openid/OpenID4VP/pull/421

—————————————————————————————————————
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20250324/23c1c9d4/attachment-0001.htm>