Comments (7)
Wouldn't this be a lot easier to manage if instruments were managed by the RP Payment Handler and this could have a refresh instruments event that could be invoked by the browser occasionally?
from secure-payment-confirmation.
Wouldn't this be a lot easier to manage if instruments were managed by the RP Payment Handler and this could have a refresh instruments event that could be invoked by the browser occasionally?
@btidor-stripe had said a few times that it's important to not require an RP Payment Handler in SPC because many ACS (who will be RPs in SPC) cannot easily stand up service workers.
from secure-payment-confirmation.
Yep, having a lightweight integration would be ideal. One way to do this would be for the RP to publish a JSON document containing the payment instrument data. The browser could load the document during registration and poll it periodically for updates:
{
"id": "card_1HjWCQDMts5GS4hiDpJnadxq",
"deleted": false,
"displayName": "Mastercard ····4444",
"icon": "icon.png",
// + future data for the combined flow
}
from secure-payment-confirmation.
Hi @btidor-stripe. Interesting proposal. Is the idea to have a single manifest file (JSON doc) for all Id's served by an RP (the Issuer), or would there be a separate JSON document for each 'user' or 'card'?
And how would the linking between a payment mechanism and a credential (Fido token) be setup? Still with a navigator.credentials.create instruction by the RP? This would this then be to allow
- Updating for Displayname and Icons
- Removal of old entries?
from secure-payment-confirmation.
Hi @Goosth, that was my idea -- having a separate manifest per instrument! There's a lot of flexibility in how the manifest could be registered, but linking it in the navigator.credentials.create
call makes sense to me. Like you said, this would enable the issuer to update the displayName and icon, as well as remotely deprovision the instrument (e.g. to clean up when a user freezes or de-registers a device from their online banking portal).
This is just one suggestion, though!
from secure-payment-confirmation.
In the architecture that @ianbjacobs and I were working on the PaymentCredential
(somewhat akin to the existing Payment Handler concept of "instruments") could have a URL as an identifier.
This would allow the browser to refresh the data at any time by simply doing a fetch on the URL.
The fetch would need to include client credentials (now I mean cookies... credential is VERY overloaded) it has for the RP origin otherwise anyone could fetch the data (possibly not an issue but need to explore).
from secure-payment-confirmation.
The API has evolved so that instrument display information is provided as input at authentication time. I am going to close this issue.
from secure-payment-confirmation.
Related Issues (20)
- Add issuer and payment system logos to transaction dialog HOT 5
- i18n Review Checklist for Secure Payment Confirmation (headed to CR) HOT 1
- Broken "Object" xref in § Set SPC Transaction Mode HOT 2
- language and direction metadata needed? HOT 6
- Error example contains a hardcoded string HOT 1
- Term 'monkey-patch' may not be inclusive? HOT 1
- `DOMString` for `payeeName` vs. `USVString` for other fields? HOT 1
- Add locale hint for browser UX
- Proposal: Remove User Activation requirement for authentication HOT 1
- Use lowercase values in enum HOT 11
- Register SPC-related WebAuthn extensions in IANA registry HOT 8
- Broken references in Secure Payment Confirmation
- Example of `locale` member HOT 3
- I18N problem with displayName unresolved? HOT 3
- [PING] Only allow triggering authentication from a foreground tab HOT 4
- Broken references in Secure Payment Confirmation
- Broken references in Secure Payment Confirmation
- Add Support for Cross-Device Authentication HOT 2
- Implementing a time out for fallback UX HOT 1
- How will new passkey providers impact SPC HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from secure-payment-confirmation.