Comments (4)
Thank you, @tblachowicz. Based on your note, I propose that we conclude that how keys are exchanged is outside the scope of a W3C payment method. I have added this sentence to the payment method description:
"How keys are exchanged (during onboarding or at other times) to enable the encryption of part of the payload is outside the scope of this payment method."
from src.
Also, see the early draft of encryption
from src.
The Checkout API returns encrypted Payload
containing payment credentials and/or personal Consumer details. The encrypted data is compliant with JWE and the EMVCo SRC API specification [1] only indicates recommended algorithms to use, but the details on how the keys are exchanged are out-of-scope for the spec.
Note, in the spec, there is section "5.8 Public Key Retrieval" containing details on how SRC System is expected to publish cryptographic keys as JWK keyset. However, the section is only limited to keys used for digital signature verification between SRC Systems and other participants.
from src.
Closed this issue at 12 June teleconference [1]; there was support for the proposed sentence in the payment method specification.
[1] https://www.w3.org/2019/06/12-wpwg-minutes#item03
from src.
Related Issues (20)
- How should assurance data in the response be modeled?
- Token and token reference use cases HOT 2
- Do we need payloadTypeIndicator? HOT 3
- Is EventHistory useful for the Payee
- Is support for custom input/output data required?
- Missing ServiceID in request data
- What request data do we need to support 3DS from the payment handler? HOT 1
- What are user journeys with SRC payment handlers?
- Consumer Identity Mapping
- Can we align AssurancePreference with SRC 3DS Preference?
- Allow for custom data to SRCI
- Can common payment handler be used for card-on-file updates?
- Maybe avoid mention of hasEnrolledInstrument for now? HOT 1
- Make the arc document a markdown doc HOT 2
- Try to remain vendor neutral HOT 3
- Phishing-resistant HOT 1
- SRC-I not defined HOT 1
- Browser-specific manifest instructions HOT 1
- Defining behavior in different SRC-I availability scenarios HOT 1
- expand acronym
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 src.