Meeting minutes
Note: This is a joint discussion of WPSIG, VCWG and FedID WG. Minutes are public.
Background
Ian: Joint meeting. DPC updates most from EMVCo and FIDO but W3C updates welcome. Also: what do we want to cover at TPAC in a joint meeting?
What are DPCs?
(Sami Tikkala presents slides on behalf of digital identity and payments task force of EMVCo)
Sami: I'll go through first what EMVCo's task force has done.
… we have defined an EMVCo digital payment credential schema
… this relies on a variety of other technologies
… a year ago when we started this work, we saw the need for a payment card schema in the verifiable credential context.
… our scope at EMVCo is payment cards but we are collaborating with FIDO on other schema topics.
… we've added a role for a requestor
… so we have a four-corner model: credential holder, credential issuer, credential requestor, credential verifier
Sami: We'd like the schema to work across jurisdictions but we've not yet formulated it for a specific regulation
… we are not directly defining lifecycle, security model, trust framework models....allowing for flexibility
Albert: In the four corner model, who do you see fulfilling these roles?
Sami: For the requestor, it will be the entity that interacts with the cardholder.
… verifier might be something that we consider updating at some point to avoid confusion with the three-corner model.
Albert: Sounds like there is flexibility; that's good
Sami: From a tech viewpoint, the roles can be held by different parties.
Manu: I don't see anything incompatible with the VC model.
… we'd love to chat with you to ensure alignment as the EMVCo work progresses.
… the VCWG has done work to ensure that the model works in payments and other areas.
… we're happy to work with you to align terminology
Sami: Thank you; that's why we're here today.
(Sami walks through flow through four corner model)
Sami: The upper left corner of the model is where open standards play a key role.
… but lower right corner (verifier) is more likely to be "proprietary" where, in the card world, it's likely to be different programs that are proprietary with business rules, technical rules, and other requirements....e.g., between card networks, ACS, issuers
Hicham: Regarding separation of roles...does the requestor forward presentation?
… does the wallet see the requestor as who they need to authenticate?
… what is encrypted?
Sami: Most likely, the roles we see here are "conceptual" but what specifically a role does may be implementation specific.
Sami: We have a "Schema Framework" document that is currently under public review
Sami: technical bindings are defined in annexes.
tomasz: In the schema we define a generic schema and two bindings (SD-JWT and MDOC)
Manu: We have VCWG participants here today; are you interested in mappings to the VC model?
Tomasz: We'd be open to that .But ideally there would just be one format.
Manu: We have work going on in W3C mapping VCs to payment credentials.
… all of us agree that it would be nice to have one credential format, but that ship has sailed
Tomasz: Yes, it would be beneficial to us to connect. I'd be very interested in talking with you about that.
Matthew_Miller: In the 4-party model you have an additional partner. Is it too early to talk about trust registries in a general sense?
… has EMVCo thought about what the ecosystem looks like for issuers/holders
Sami: We've not worked at that EMVCo but some work is happening in EIDAS LSPs
… EMVCo has not yet defined those
Matthew_Miller: Does anybody foresee 4-corner model complicating trust in traditional 3-party model?
Manu: great question, and one that has a complicated answer. We've had that discussion for many years; there are differences between models. 4-party is not incompatible with 3-party, but there's a different actor.
… key point is that the models can be aligned.
<manu> Hicham: Who is expected to vet the payee name and model?
<TallTed> Could we also get a link to today's main slidedeck?
Tomasz: It's a good question, we are looking into that at FIDO
Tomasz: This has to do about trust between verifier and requester and holder -- it's not for EMVCo to solve, we are working on it.
john: What might be called the 4 party model isn't unique to payments, in European LSPs -- it's common to have aggregators that are the web origin, but not necessarily the trusted party. Could be 4-5 different government agencies going through one aency. In some ways, three party devolves into four party - yes, we need to think about generalization and take into account web origin requestor might not be party result should be encrypted to. There are
additional roles that need to be define when it comes to various trust things in harmonization WG, take some of things into account.
Tomasz: This depends on use cases / payment flows -- who is the party that should be trusted?
Tomasz: The verifier is making the request, the requester is just facilitating... receiver of presentation and decrypt the presentation is verifier, not requester.
JohnB: The web origin of the requestor is not necessarily the identity of the verifier and may need to be represented differently.
… the requestor may need to be represented in the dialog as, say, a merchant. And the verifier might be the acquiring bank or network.
… the question is: how is this information presented to the user in a sensible way?
… the verifier may not be something the user understands. It's the bank of the merchant, not the user bank.
tomasz: Good point; we can't rely on the end user to verify the authenticity of the entity
<TallTed> "[...] Verified by [...]" might well be something that gets displayed to a human or agent performing some actions.
JohnB: What functionality does the wallet need to be proven to enforce so that the user has confidence? There's a wallet certification component
tomasz: We'll have a set of requirement for wallets and can discuss the FIDO group doing wallet certification
stephen_mcgruer: While I agree the 4-party model is important to understand, at the end of the day you are handing the DC API result to the requestor. The user's relationship with the verifier is not exactly relevant or enforceable.
JohnB: If the verifier encryption credentials are passed to the wallet and the wallet only verifies to that, I think it's relevant
stephen_mcgruer: That's fair.
JohnB: In some discussions there is discussion about wallet results being encrypted and the question is "to whom"?
… we don't want other PII disclosed to random merchants.
… in general, the merchant should see the minimum it needs to see
FIDO Alliance update
(Nishant Kaushik presents FIDO Alliance update slides)
Nishant: FIDO Alliance working on the transaction data elements.
… and looking at validation requirements that wallets have to go through, interop rules, and handling cryptography
… does not assume any payment scheme or credential format
… it's meant to be used for non-card payment models as well
… the work complements the EMVCo initiative; addressing other payment types and not overlapping EMVCo's scope
… the FIDO Alliance is providing feedback to EMVCO on their schema framework, and also leveraging that framework.
… there is a need identified around wallets; that's where there is intra-FIDO discussion between the tech WG and the certification group.
… I don't think the four party model has been explicitly discussed yet, but I assume will be coming into the digital credentials wg at FIDO
<nicktr> recurrence is a really difficult context to frame. It can get super complex very quickly (initial amounts, varying cadence, varying amount, open mandates, time limits, count limits, calendar months, weeks, days, daylight saving, time relative to location of payer, payee...).
Nishant: A follow-up meeting in a few months on this would be useful.
… we are planning right now on having something substantial developed by October
… we want to coordinate with W3C as well
… want to converge on data models, terminology, etc.
Next steps
Ian: We can chat at TPAC.
… should we meet before then in this forum?
Arman: We've had a bit of an overview of DPCs and some activities.
… I think it's helpful to use to understand better the current work and expected future work in the other W3C groups.
… could we meet again with these bodies in this forum before TPAC?
<Zakim> manu, you wanted to extend an invitation to engage with the VCWG async - bilateral, to focus on providing examples, etc.
Manu: +1.
… regarding bilateral engagement, the VCWG would like to engage directly with EMVCo.
… before TPAC
… and +1 to meeting at TPAC
Heather: Speaking for FedID, we are hoping to get to CR for DC API this year. So getting review in advance and ensuring fit for purpose is appreciated.
Ian: I will update the meeting description for Tuesday 13:15-15:00 to include FediD and VCWG and we'll talk about this more
ACTION: Ian to schedule a w3c update on DPCs and DC API for folks here, before TPAC.