Meeting minutes
BBKs
w3c/
(We review the questions)
John: Acknowledge the issue around vague definition of "account"
Ian: Do we need changes anywhere?
John: Suggest clearer information in the spec
John: A note might be fine.
Ian: Might need to be normative.
Ian: Is a more crisp definition needed to unblock usage of the API?
ACTION: Darwin to chat with Stephen about whether spec change / clarification is useful
SPC and roaming authenticators
JohnB: Let's wait for result of discussions a bit longer
We postpone the discussion to 7 May.
Currency code question
https://
(Question: what is status of ISO4217 codes?)
ACTION: Ioana will reach out to ISO group to see what there plans are about cryptocurrency codes
https://
<sidvishnoi> the note in PR in question: https://
FYI - survey on impact of AI
John: We'd need to divide up what AI will impact.
… SPC is designed to stop AI
Jean-Luc: There are two trends - using VC and using passkeys
… it could be interesting to capture the user intent via something like SPC (transition data enhancement)
jean-luc: If there is an existing trust relationship, the user would consent to authenticate a transaction. There would be differences between trusted relationships and untrusted relationships
… could be interesting to think about expanded transaction data.
… to a kind of authorization context.
John_Bradley: I agree that taking advantage of SPC makes sense there, but do we need a general purpose API or payment-specific?
Jean-Luc: A big issue is how to trust UI (which we get with SPC)
… but we can't shopping agent UI
John_Bradley: That could be an interesting angle to explore
NickTR: Today in the EU you need explicit information about merchant and amount at the point of authentication for the transaction.
… so payments can't make payments autonomously and comply with dynamic linking
jean-luc: Indeed, but the short term use case will be human-in-the-loop
NickTR: This takes us back to conversations we've had about SPC in native apps.
Ian: My sense from TPAC was that the DPC folks said "Don't expand use cases."
John_Bradley: But SPC may make it easier too prove that there was a human in the loop (may be useful for PSD2)
… because FIDO requires user interaction.
Ian: Does the ARF require user interaction?
John_Bradley: There's no fundamental underlying regulation for that at the moment
… there might be some guarantees per-country
… but people are building wallets for agents that don't require human interaction
… so SPC's assumption that there's a human in the loop may give it leverage
Ian: Would "a human must be in the loop" be something to surface at the DC API layer?
John: No
… it would likely be part of the wallet and it would be credential-specific.
… SPC is easier to reason about
John_Bradley: There's no reason your agent couldn't be a RP in an SPC flow
… the information that would be required could be passed on in SPC
… question of whether we need to add a parameter "I'm an agent that's doing this"
… if an agent were doing SPC, what would go in the client extension input data?
… we may want to add clarifying notes for when agents are using SPC
… from a protocol POV, an agent is like merchant.
… but there may be more info that's needed (merchant talking with agent)
… agent could lie about what merchant it's getting an authorization for.
NickTR: I think there's a difference between agent and merchant in terms of threat modeling.
John_Bradley: Right, it might be ok when the bank says "Yes, Claude is allowed to act as an intermediary for my credentials". If we include enough info in the assertion for the bank to make a risk decision, that would likely suffice.
NickTR: For card payments, who is vouching for the agent and its trustworthiness?
… you'd likely need some extra layer of certification so that the agent can sign over the transaction
John_Bradley: if someone wanted to build that certification ecosystem, would the API have enough hooks for the data exchange?
Jean-Luc: I think there's no liability shift in implementations I've seen.
… big point is how to have trust when AI is non-deterministic and selects merchant/products based on user intent.
John: What you want to sign over is "the merchant is best buy, my agent is claude, and I am signing this amount to allow claude to interact with best buy"
… we may need to capture this extra level of interaction.
… normally the merchant is the top origin, but it's not in this case.
Ian: I think this is similar to marketplace story, which I think SPC covers
John_Bradley: Agree an agent is acting as a virtual marketplace
… where we would have a problem is the next step
… doing SPC before the merchant has been selected v after the agent has selected the merchant
Manjush: Would the agent be operating in the browser or stand-alone?
John: Today SPC doesn't work in apps
Manjush: From a UX experience, you'd be interacting with an app. After capturing the intent, the agent might present choices to the user via a browser.
John: Might be the merchant domain or a redirect to an agent portal.
… if the agent redirects the user in a browser to a merchant, we don't need to change anything
<nicktr> I would note that PSD3 and the upcoming PSR have pretty trenchant views on agents - broadly I would say that they will remove the limited agent exclusion
Upcoming meetings
7 May