[Openid-specs-digital-credentials-protocols] [agenda] DCP WG + SIOP call (PST 8am) - focus on transaction data in payments and QES use-cases
Brian Campbell
bcampbell at pingidentity.com
Fri Aug 9 16:25:35 UTC 2024
Just a pedantic clarification, the content at those URLs will eventually
change. These are links to stable content of the respective draft
versions:
https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-14.html
https://openid.net/specs/openid-4-verifiable-presentations-1_0-21.html
On Fri, Aug 9, 2024 at 7:44 AM Kristina Yasuda via
Openid-specs-digital-credentials-protocols <
openid-specs-digital-credentials-protocols at lists.openid.net> 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
>>
> --
> Openid-specs-digital-credentials-protocols mailing list
> Openid-specs-digital-credentials-protocols at lists.openid.net
>
> https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols
>
--
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
material for the sole use of the intended recipient(s). Any review, use,
distribution or disclosure by others is strictly prohibited. If you have
received this communication in error, please notify the sender immediately
by e-mail and delete the message and any file attachments from your
computer. Thank you._
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20240809/40c0c260/attachment-0001.html>
More information about the Openid-specs-digital-credentials-protocols
mailing list