[Openid-specs-digital-credentials-protocols] [agenda] DCP WG + SIOP call (PST 8am) - focus on transaction data in payments and QES use-cases
Kristina Yasuda
yasudakristina at gmail.com
Tue Aug 13 19:02:28 UTC 2024
Hi All,
Here is the deck from the payments use case presentation.
Best,
Kristina
On Fri, Aug 9, 2024 at 3:43 PM Kristina Yasuda <yasudakristina at gmail.com>
wrote:
> Hi All,
>
> Thank you very much for joining our WG call yesterday on transaction data
> in payments/QES use-cases.
>
> *The latest WG drafts of OpenID4VCI (draft 14) and OpenID4VP (draft 21) *have
> been published (this is not an implementer's draft, the purpose is to have
> a stable text at a certain URL):
> -
> https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html
> - https://openid.net/specs/openid-4-verifiable-presentations-1_0.html
>
> *Please find minutes from yesterday's meeting *here:
> https://docs.google.com/document/d/1HraJMjjpOnWuOyBy2g0eRbF0kELtyGCPd97xEh-vQ2E
>
> Per OIDF policy, I am copy pasting the text in this email too, but the
> google doc is probably more readable.
>
> I am also attaching slides from Mark on QES. Payments slides will be
> circulated shortly.
>
> If anyone wants the recording, please reach out to me or Joseph.
>
> Best,
> Kristina
>
> ---minutes below---
> Attendees
>
> Brian Campbell
>
> Luis
>
> Martijn Haring
>
> John Bradley
>
> nemanja.patrnogic
>
> Nels (Google)
>
> Lukasz Jaromin
>
> Pamela Dingle
>
> David Chadwick
>
> Bjorn Hjelmbjorn.hjelm at oidf.org
>
> Juba Saadi | Lissi GmbH
>
> Christian Bormann
>
> Gareth Oliver
>
> Andy Lim
>
> Hicham Lozi [Apple]
>
> Paul Bastian
>
> Jin Wen (Nok Nok Labs)
>
> Can Avunduk
>
> Greg Owen
>
> Michael Jonesmichael_b_jones at hotmail.com
>
> Jan Vereecken
>
> Sebastien Bahloul (IDEMIA/AFNOR)
>
> Ranjiva Prasad
>
> Steve Venema
>
> Andreea Prian (iDAKTO)
>
> Tim Cappalli (Okta)
>
> Rajvardhan Deshmukh
>
> Ed Curran
>
> Stefan Kauhaus | Visa
>
> Alistair Hughes (Google)
>
> Pedro Felix
>
> Willie Mays (us-sfo-1mst)
>
> Lee Campbell
>
> Torsten Lodderstedt
>
> Kristina Yasuda (OIDF)
>
> Daniel Fett
>
> Dr. Mark Ullmann | D-Trust
>
> Scribe: Luis Vargas <paymentsluis at google.com>
> Notes
>
> Stefan Kauhaus - Presenting EWC
>
> -
>
> Stefan Kauhaus (Visa):
> -
>
> Coming from the EU Identity Wallet
> -
>
> Visa in the EWC consortium
> -
>
> Shared the legalese of EIDAS2, PSD2 as the motivation for the work
> (see slides for details)
> -
>
> Ranjiva Prasad (Visa)
> -
>
> In the ARF every attestation and credential is bound to a separate
> key
> -
>
> The key is specific to the attestation
> -
>
> The key binding proof will be signed attestation is this the SCA
> that will be passed to the issuer (APSP)
> -
>
> David Chadwick:
> -
>
> Why are we adding application specific logic into OpenID4VP. Shouldn’t
> banks create a new application protocol for this use-case and then embed
> OpenID4VP in that?
> -
>
> Stefan Kauhaus (Visa):
> -
>
> We need to work with existing EUDI wallets that only support
> OpenID4VP. Doesn’t make sense to build another protocol as the EUDIWs are
> not mandated to support it
> -
>
> Torsten: Agrees
> -
>
> Ranjiva Prasad (Visa):
> -
>
> We believe this is generic enough to add to openid4vp. It's a
> generic transaction signing feature.
> -
>
> Came up with the idea of using the signature over the presentation
> as a sign of the will of the user to authorize the transaction
> -
>
> Torsten & Lee: Not sure what you mean by key or “payment wallet
> attestation (PWA)”? Do you mean a credential of some sort?
> -
>
> Stefan Kauhaus (Visa):
> -
>
> The payment wallet attestation (PWA) is to prove that the wallet
> went through the registration process
> -
>
> Yes, we mean a credential that's provisioned to the wallet, like
> any other EAA.
> -
>
> Torsten & Lee: Then we should name it as such, for a example a
> Payment Credential
>
>
>
> -
>
> Paul Bastian:
> -
>
> For transaction signing it is worth considering using a different
> credential format that is purpose built for payments
> -
>
> The important point is to connect the payment to the credential
> -
>
> Lukasz Jaromin
> -
>
> The EWC/Potential proposals are very Europe specific, and
> OpenID4VP is not only for EU
> -
>
> Stefan Kauhaus (Visa) : Exactly that’s the reason we (EWC) are not
> trying to be too prescriptive on something that will be used differently
> around the world. The mechanism would be an arbitrary JSON object.
>
>
> Mark Ullman (MU) - Potential
>
> -
>
> Use case 5 of the Potential LSP: Qualified eSignature
> -
>
> Qualified Electronic Signatures, one level over the Advanced
> electronic signatures which is what (Recital 26 of the EIDAS2 regulation)
> encourages Member States to consider in the day-to-day transactions provide
> a sufficient level of security and confidence.
> -
>
> The wallet user would get a request to confirm
> -
>
> The wallet will return the transaction data, upon return we will
> compare that it is the same that was linked to the PID or the credential
> -
>
> It is more than signed presentation, because the signature is
> associated with the transaction
> -
>
> Feedback:
> -
>
> This is a new type of application code that will be required the
> application of the protocol in the verifiable presentation
> -
>
> Lee:
> -
>
> There are different possibilities to do the signature
> verification
> -
>
> What does the dtbsr abbreviation stand for? Data to be signed
> representation
> -
>
> Torsten Lodderstedt (TL):
> -
>
> There are 2 ways to sign certificates: One requires data to be
> signed, the other requires hash
> -
>
> CSC (Cloud Signature Consortium)
> -
>
> Andrea Prian (iDAKTO)
> -
>
> Concern on who can access the presentation
> -
>
> Torsten Lodderstedt (TL): The problem already exists, it just
> became obvious with transaction data
> -
>
> One option is to send encrypted data to the wallet
> -
>
> Lee:
> -
>
> If it is Javascript from the browser to the wallet, there
> is no one to protect against it
> -
>
> The only thing that will see it is the operating system,
> which sees every pixel in the screen
>
>
> -
>
> Lee asked Visa to show a slide containing an example of the
> parameters they would include in the transaction data
> -
>
> Ranjiva Prasad (RP)
> -
>
> Action item: Visa will present an example slide of what it would
> be look like, which would be different for a card account, bank account,
> will add this to the deck
> -
>
> Mark Ullman:
> -
>
> There is an interest in standardizing. The EUDIW is governed by the
> European Telecommunications Standards Institute (ETSI)
> -
>
> If a wallet receives a request and it does not recognize it, it
> will just reject it
> -
>
> Kristina Yasuda (KY)
> -
>
> We expect the actual payment types to be defined by the payment
> experts. This may live in another standard. The key is that its documented
> and referenced somewhere
> -
>
> Mark: There could be a registry of these credentials.
>
>
> On Wed, Aug 7, 2024 at 7:48 PM Kristina Yasuda <yasudakristina at gmail.com>
> wrote:
>
>> Hi All,
>>
>> Tomorrow's WG call, we will focus on the use of transaction_data
>> mechanism in payments and QES (qualified electronic signature) use-cases.
>> We will have guests joining us, including Ranjiva and Stefan from VISA and
>> Mark from D-Trust.
>>
>> After our usual business at the beginning of the call (notes, IPR,
>> intros, PRs, events, etc.), I was planning something like below:
>> - 10min presentation from payments use-case and short QnA
>> - 10min presentation from QES use-case and short QnA
>> - discussion 20-30min
>>
>> Thank you!
>> Kristina
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20240813/731627b8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 240808 OID4VP for Payment Confirmation.pdf
Type: application/pdf
Size: 275273 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20240813/731627b8/attachment-0001.pdf>
More information about the Openid-specs-digital-credentials-protocols
mailing list