[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
Fri Aug 9 13:43:47 UTC 2024


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/20240809/0211e3dd/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Activation_rQES-OID4VP-transaction-data-OIDF-DCP-WG-2028-08-08_Mark_Ullmann.pdf
Type: application/pdf
Size: 661848 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20240809/0211e3dd/attachment-0001.pdf>


More information about the Openid-specs-digital-credentials-protocols mailing list