13:52:40 RRSAgent has joined #wpwg 13:52:44 logging to https://www.w3.org/2025/03/13-wpwg-irc 13:52:44 Meeting: Web Payments Working Group 13:53:00 Agenda: https://github.com/w3c/webpayments/wiki/Agenda-20250313 13:53:02 Chair: Ian 13:53:04 Scribe: Ian 13:53:08 agenda? 13:53:57 agenda+ Updates from the OpenID Foundation 13:54:20 agenda+ Updates on payments in Europe 13:54:25 agenda+ Rechartering 13:54:26 agenda+ Next meeting 13:59:43 present+ 13:59:47 present+ Richard_Ledain 13:59:52 present+ Tim_Stuart 14:00:02 present+ George_Matthew 14:00:16 present+ Alex+Poljak 14:00:20 present+ Doug_Fisher 14:00:28 present+ Martin_Alvarez-Espinar 14:00:35 present+ Arman_Aygen 14:00:42 present+ Rogerio_Matsui 14:00:47 present+ Fahad_Saleem 14:00:50 present+ Jianhua_Ni 14:01:03 present+ Clinton_Allen 14:01:08 present+ Steve_Cole 14:01:26 present+ Bjorn_Hjelm 14:01:42 present+ Stephen_McGruer 14:01:47 present+ Yoshiyuki_Sakata 14:01:50 present+ Array 14:02:04 present+ Arayu 14:02:33 present+ 14:02:35 present+ Lewis_Falls 14:02:42 present+ Frank-Michael_Kamm 14:02:44 SameerT has joined #wpwg 14:02:44 Fahad has joined #wpwg 14:02:46 present+ 14:02:53 Present+ 14:02:56 present+ David_Benoit 14:03:00 Bjorn has joined #wpwg 14:03:04 present+ Torsten_Lodderstedt 14:03:11 martin_alvarez has joined #wpwg 14:03:15 present+ Sameer_Tare 14:03:15 present+ 14:03:17 present+ Rouslan 14:03:26 doug has joined #WPWG 14:03:31 JonM has joined #wpwg 14:03:39 present+ Carey_Ferro 14:03:43 ClintonA_AMEX has joined #wpwg 14:04:00 present+ Kristina_Yasuda 14:04:32 zakim, take up item 1 14:04:32 agendum 1 -- Updates from the OpenID Foundation -- taken up [from Ian] 14:04:36 Alex5 has joined #wpwg 14:04:36 Roger has joined #wpwg 14:04:43 present+ Takashi 14:05:06 Fahad has joined #wpwg 14:05:51 Steve_C has joined #wpwg 14:06:10 George has joined #wpwg 14:06:19 Kristina: Torsten and I are co-chairs of digital credentials protocols wg in OIDF 14:06:52 ...today we'll mostly talk about openid4vp and openid4vi 14:07:12 present+ Pierre-Antoine_Champin 14:07:21 present+ Vasili 14:07:53 present+ Gerhard 14:08:00 present+ Sami_Tikkala 14:08:03 vasilii has joined #wpwg 14:08:34 Kristina: Vertical profiles sit upon the protocols. 14:09:00 ..pan is to publish 1.0 final of openid4vp, openid4vci, and HAPI around June 2025. After that we will not make breaking changes after 1.0 14:09:19 s/pan is/plan is 14:09:40 Kristina: We have lots of interop events happening 14:10:05 ..if you want to read the specs: VP=>24; VCI=>ID-2; HAPI=>iD-1 (coming soon) 14:10:11 pchampin has joined #wpwg 14:10:37 Kristina: There's a lot of introductory material about the APIs online. 14:10:43 ...hot topics today are: 14:10:49 - DCQL (query language) enhancements 14:11:04 ...this came as a close collaboration with the Digital Credentials API 14:11:08 Jianhua has joined #wpwg 14:11:37 ...the wallet and verifier now have direct communication 14:12:12 ...more on Transaction data => binding user interaction with how the user authenticated. 14:12:25 present+ Tim_Stuart 14:12:32 present+ Sharanya 14:12:36 present+ Sue_Koomen 14:13:15 Kristina: We now have support for multi-relying party requests 14:13:22 ...and wallet attestation during presentation 14:13:41 ...attestation is more important at issuance, but there are use cases for presentation as well. 14:14:05 Torsten: Regarding transaction data for payment authorization 14:14:16 ..this was introduced in summer 2024 for two use cases 14:14:38 ....using capabilities of the wallet to bind a decision of the user of the wallet with a certain transaction (e.g., transaction confirmation, signing a contract) 14:14:53 ...the wallet shows it to the user and the user signs the data with a key that is bound to a certain credential. 14:15:06 ....thus, we bind the identity and the decision. 14:15:34 ...the request is a presentation request (the RP asks for the presentation of a credential) 14:15:53 ...on top of that, they ask to display some terms and conditions for the user's agreement 14:16:08 ..the wallet creates the proof of possession to sign a presentation object 14:16:25 ...this object would include the displayed data, which is sent back to the relying party (the merchant, for example) 14:17:05 present+ Praveena 14:17:09 present+ Rene_Leveille 14:17:46 (Torsten shows JSON representation of dcql query and transaction_data) 14:18:41 ....the response (the sd-jwt) includes the confirmation claim ("cnf") that includes the public key used to do the proof of possession. 14:19:36 Torsten: We are discussing 2 use cases: use of feature to authorize a credit transfer and (2) payee-requested flow. 14:20:06 ..in case 1, the wallet is the bank's wallet (so the bank has evidence of consent of the credit transfer). 14:20:29 ...for payee-requested flow, the bank provisions the credential into the wallet, but then the presentation request is sent by a merchant. 14:20:30 q+ to ask (1) about structure of PaymentRequest data, (2) what happens if the wallet doesn't reply with support (or if there is no wallet) 14:20:53 ...the merchant gets back a presentation, which authorizes the payment, and then the merchant can put that in their payment API 14:21:12 ack smcgruer_[EST] 14:21:12 smcgruer_[EST], you wanted to ask (1) about structure of PaymentRequest data, (2) what happens if the wallet doesn't reply with support (or if there is no wallet) 14:21:51 smcgruer_[EST]: On the PaymentRequest object; one thing we've heard with SPC (which is similar) is a lot of demand to meet other use cases like recurring payments. 14:22:03 ...we've struggled how to encoded those use cases in structured data 14:22:22 Torsten: That's our experience as well. We as openID Foundation don't standardize payments; just the rails. 14:22:39 ...we have defined a transaction data feature as an extension point (with a "type" attribute) 14:22:59 ...EWC is one of the LSPs in Europe looking at the payments use case. 14:23:12 ...and the use of the transaction data 14:24:00 ...there's a lot of testing going on right now in the EU. Kristina and I are involved, and are providing prototypes to the LSPs. 14:24:03 ...we'll be testing this year. 14:24:28 smcgruer_[EST]: What if the wallet doesn't support the "type"? 14:24:43 ....what happens if no wallet is appropriate or replies? 14:25:06 Torsten: If a wallet doesn't support a transaction type, it refuses. 14:25:57 Gerhard: We've also defined in the WPWG a structure. Should we go to OIDF to get an SPC payload data standard? 14:26:10 ...how to standardize different transaction data formats? 14:26:40 Torsten: that's an important question. We haven't really decided on that yet. I think it makes sense to have a list of definitions. But I don't think OIDF will do the definitions. 14:27:38 Ian: Any discussion of type being a URL? 14:27:43 Torsten: Yes 14:30:05 [Torsten drops off] 14:30:37 (We look at QES in QTSP centric model) 14:31:35 Kristina: The dcql_query is top-level transaction data. The transaction_data uses a URL-based type, and the transaction data can be bound to whatever the credentials the user has (so it's an array) 14:31:44 ...there are a number of claims defined by the type 14:31:59 ...and a hashAlgorithm specification that will go in the response. 14:32:11 durkinza has joined #wpwg 14:32:15 ...we are looking to change the response structure to make it more credential format agnostic. 14:32:44 ...our use cases are mostly around sd_jwt. If there is interest in using mDOCs or other credential format, that should be discussed. 14:33:25 [On OpenID4VCI] 14:33:36 Kristina: the biggest update is batch issuance of credentials. 14:33:50 ...if the user keeps presenting the same credential everywhere, that may lead to tracking. 14:34:05 ...batch issuing varies the signature to reduce risk of tracking. 14:34:26 ...another important feature is wallet attestation and key attestation 14:34:40 ...it's an important security feature that the key has been validated by the issuer. 14:35:00 ...another important topic is credential lifecycle. 14:35:28 ...we differentiate "credential configuration"; the actual credential where the data is filled in already, and the copy of each credential. 14:35:57 ...so for example, one might issue 3 educational diplomas where there are minor variations but the same schema 14:36:05 ...we also simplified the protocol to remove unused features. 14:36:19 ...we are still working on some topics: (1) deferred issuance (2) cleanup 14:36:47 ...for example, in some cases, one might authenticate the user and then issue credentials 24 hours later. 14:37:04 ...in general the specs allow for different architectures (e.g., with or without wallet backend) 14:37:49 Kristina: We are aware that the work of issuance over browser API is also happening. 14:38:27 ..issuance can involve a wallet selection challenge 14:39:00 Fahad: can an issuer indicate what wallet they want to store the credential in (in issuance)? 14:39:21 Kristina: Issuance is much closer to the Oauth model. 14:39:38 ..when the wallet sends a token request to the token endpoint, that's where the wallet attestation kicks in 14:40:14 ..in the EU we expect that the wallet instance running on the user's device will have an attestation that the wallet is certified by the German government, for example. 14:40:25 ...the issuer will get the attestation. 14:40:28 ...and can make a decision 14:40:40 ...but the protocol may also support preferences in the metadata 14:41:34 Fahad: the use case we have: we have two banks. Bank 2 is issuing a credential and wants its credential to go to their wallet. If there's no mechanism, it will be weird for the user. 14:41:45 ...so we need to enable the issuer to target a particular wallet. 14:41:59 Kristina: Can you use claim URLs for that use case? 14:42:28 Fahad: The assumption is that the payment profile is standardized. So two wallets could say "we support this type of credential" 14:42:50 Kristina: This problem is not solved in the MDL profile, for example. This could be solved in a payment specific use case. 14:42:59 ...but I think the URL is best way forward 14:43:20 ..OAuth works like that - you know the client you want to work with and can pre-exchange metadata. 14:43:33 ..if you know 1-1 matching, that's easier to implement. 14:44:29 present+ Holger_Kunkat 14:44:41 regrets+ Lee_Campbell 14:45:00 [We look at HAIP updates] 14:45:04 fs has joined #wpwg 14:45:37 ...now a collection of 4 profiles that can be used independently (including using Digital Credentials API) 14:47:19 Kristina: In the ipenid4vp spec, section 9 (Wallet Invocation) supports URLs as domain-bound as authorization_endpoints. 14:47:31 ...this would support opening of a targeted wallet. 14:50:18 Ian: Any alignment possible between the SPC data model and transaction data type=PaymentRequest? 14:50:33 Rouslan: I think it would be useful to align data models and descriptions. 14:51:03 q+ 14:51:12 ack smcgruer_[EST] 14:51:37 smcgruer_[EST]: I think it is useful to align the data model. But we should figure out who are working on the transaction model for alignment. 14:51:57 ...in SPC we are going to be adding information about the issuers (e.g., logos) in the UX 14:52:17 ...but that may not be necessary in digital wallet context since the wallet is expected to have the context 14:52:27 ...so presenter of data may be different in SPC case than in wallet case. 14:52:39 ...but there might be use cases where there is overlap. 14:52:50 ..maybe there are cases where information is not yet associated with a credential. 14:54:12 (We talk about UX of digital wallet selector) 14:54:40 sami has joined #wpwg 14:55:02 present+ KaRa 14:56:28 Kristina: We know there are issues with wallet selection and cross-device security. 14:56:36 ...we need *some* API to solve these 14:57:08 ...in rechartering discussion some ideas for discussion are (1) profile (2) registry 14:57:56 ..transaction data is a small piece. We'd like to make sure that the HAIP matches your own needs 14:58:13 ...and there might be a profile that is created "Use HAIP this way for this use case" 14:59:54 RRSAGENT, make minutes 14:59:55 I have made the request to generate https://www.w3.org/2025/03/13-wpwg-minutes.html Ian 14:59:58 RRSAGENT, set logs public 15:28:33 TallTed has joined #wpwg