2024-08-12 (A Call)

Organizer: Tim Cappalli

Scribe: Helen

Agenda

• Administrivia
  • 8/21 call canceled
• TPAC sessions
  • https://www.w3.org/2024/09/TPAC/schedule.html#monday
• Issues Needing Action
  • Define error handling (#130)
• Issues for Discussions
  • define a well-known way for a verifier to indicate registration, validation, trustmark assurances or other necessary info (#136)
• Kick off payments discussions

Attendees

• Tim Cappalli (Okta)
• Helen Qin (Google Android)
• Andrew Regenscheid (NIST)
• Wendy Seltzer (Tucows)
• Mike Jones (Self-Issued Consulting)
• Rick Byers (Google Chrome)
• Ted Thibodeau (he/him) (OpenLink Software)
• Brian Campbell (Ping)
• Mohamed Amir Yosef (Google Chrome)
• Chris Needham (BBC)
• Ashima Arora (Google Chrome)
• Manu Sporny (Digital Bazaar)
• Hiroyuki Sano (Sony)
• Lee Campbell(Google Android)

Notes

Administrivia

See above

Issues Needing Action

Define error handling (#130)

Sam: Key requirement for the privacy model: when can an error reveal the existence of a credential?

Rick and Lee: A user declining to share should not reveal the (non)existence of a credential. Once into the wallet post user selection, specific technical errors may be sent back (e.g., validation failure). Otherwise, if a single generic error is always propagated, it may be too hard for RP to debug.

Rick: Do we need to tackle the specific errors at the browser API layer? Shouldn’t it be tackled at the protocol layer (e.g., OpenID4VP)?

Tim: Would it be weird to have success at the browser API layer and failure at the protocol layer (e.g., in Webauthn, validation failure is defined at this browser layer)?

Rick: Would it be OK to say that this layer cannot be failed by a wallet, i.e., it only fails upon a platform failure?

Tim: Front end may not be able to decrypt the response to get the error code (e.g., OpenID4VP).

Matthew Miller: Clarifying what’s communicated at the API layer and what at the protocol layer

Lee: At the API layer, the failure is around failure getting to a wallet. Once getting to the wallet, the response/error is communicated at the protocol layer. Still a similarity with the WebAuthn.

Mat: What’s then possible to fail at the protocol layer?

Lee: Failures processing the response, e.g., validation failure.

Manu: +1 for sharing the least amount of info from the wallet to the RP. We have not found a need to send detailed errors to the RP on what went wrong. Hard to standardize detailed errors based on our implementation experience. Most useful use case is to debug a runtime error that occurs at scale. Otherwise not very useful.

Tim: Queue closed. Please add more comments to the issue. We will discuss it on the next call.

Payments

Tim: The purpose of this is a kick off, getting the conversations started, creating some issues.

Lee:

Going to provide context of the conversation going on, how we are thinking about it.

Started from the eIDAS SCA requirement. How to support this.

Solution comes down to using this digital credential API. The credential represents a method of payment. Could be a debit card, a credit card, or straightly an account number. Start from an issuance flow, from a banking app, a wallet, ending up with such a credential sat in the wallet.

Payment flows: 1. Payment confirmation flow. Today they do a 3DS redirect in Europe. Lots of failures can happen during this flow. Everyone loses out from the clunkiness. For this flow, API is invoked representing a query of “Can you verify a payment matching this payment method of this amount …” 2. 1. Checker API. Merchant hasn’t collected the payment information in this case. They declare they accept certain payment methods. Call this API to query the options. Get a payment response. Solves the problem of having to draw all the different payment options. Similar to what FedCM is solving.

Why this API? Why are the EU folks looking at this API? 1. Mandate to support OpenID4VP & reliance on this API 2. 1. Mandate to also support identity credential sign in. Using this protocol, you can present both at the same time.

Manu: Involved in starting the w3c payment work. It was hard to support this additional use cases due to the focus on the payment solution. In the US, we are looking at multi-shot credential presentations for retail use cases in retail standard bodies, e.g., TruAge. If digital credential API would support it, it would be quite trivial to get the US retail sector behind this. 75% through in terms of that standardization process. Highlighting the need for this support for multiple types of credentials at the same transaction.

Rick: Can you talk more about this one-shot design, does it limit the use cases?

Lee: Not really. Most of the requirement is still one-shot while supporting returning multiple things in this one-shot transaction. One caveat is this query API to query whether the flow can succeed before making the query.

Tim: Does it have to be one-shot? In the real world, you provide your id, and then you pay.

Lee: Getting push-back for this real world analogy to justify users having to tap (present) multiple things multiple times, one at a time. This enables these new use cases.

Matt: Example of where one-shot makes sense: pay at Target. You only need to present your loyalty card once, because it's both loyalty and payment. Worth thinking about this since there’s already these out of band support built.

Tim: Clarified: that’s a closed-loop use case, though.

Manu: For retail, you don’t want to slow down the check out. Most retailers want to push the point of sale system to the individual’s phone to allow them to speed up the checkout process. Sometimes multi-shots, sometimes one-shots. You have to design for both. If we just look at the high volume use case of paying for alcohol and verifying age, that is a one shot thing. The lawyers and the industry are already there.

Lee: Accessibility point of view, if you're blind and do tap and pay today, you don’t know how much you’re paying. Through this API we allow for a screen reader.

Tim: We need to be coordinated with other efforts. SPC is there. Parameters to the API should be common across these different APIs. There’s a lot of overlap. Open to feedback for how to coordinate these topics.

Lee: It does feel fragmented, and I don’t have a good answer for how to bring these APIs together.

Tim: Need to understand what SPC do and can’t do.

Lee: SPC problems to me: Per card passkey is suboptimal from the UX point of view. Can’t do the checker API. No obvious in-person experience. Management experience support. Multi-document presentment. Overall, there’s a growing list of things making it make sense to have a real payment credential rather than a passkey.

Tim: Dedicated joint session about this at TPAC?

Lee, can you create an issue about this?

Lee: We do need to support a multi-document presentation. Another thing that needs to get priority is issuance. Another thing to support is being able to provision the payment credential on the fly during a payment confirmation. E.g., EU ID for the payment confirmation. One time, inline, present your ID card to the bank, and then they can issue the payment. With a single fingerprint, you should be able to provision that card inline and perform the transaction.

Tim: Is this to be punted to OpenID4VP?

Lee: Maybe. But at least we need to update our behavior expectation for whether we only support single-document presentation which is the current record.

Manu: Issuance should be "high priority"

Tim: Trying to find the balance between here and openid4vp.

Tom Jones: OID4VP does not have the ability to give the user the information they need to make an informed choice

Manu: We shouldn't focus on OID4 as THE protocol that this stuff runs over.

Lee: Yeah, by openid4vp we just meant generic at that protocol layer

Manu: We need to make sure the work here is format- and protocol-agnostic. One mistake that we made in the payments working group was optimizing too early for specific use cases. We shouldn’t over-commit to a specific format/protocol too early.

Brian: Another direction we might have a problem is, we have layers and layers of things to delegate out and let them do. For now, OpenID4VP is the "protocol" layer that’s being defined. … Conversation of concern with designing without a specific query language and protocol versus being too specific and attached to one