Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add section on Extensibility #44

Closed
msporny opened this issue Mar 14, 2016 · 6 comments
Closed

Add section on Extensibility #44

msporny opened this issue Mar 14, 2016 · 6 comments

Comments

@msporny
Copy link
Member

msporny commented Mar 14, 2016

Migrating from w3c/webpayments#27:

The Web Payments WG resolved to specify how extensibility of messages is handled in the API specifications to something that looks like this:

"""
In general, the WebIDL descriptions provided in this specification outline the specific interfaces, properties, and values that an implementation may depend on. It is expected that other properties and values will be stored in objects that implement the various interfaces in this specification (e.g. PaymentApplication, PaymentRequest, PaymentAcknowledgement, etc.). While this specification does not suggest a single extension mechanism, it does anticipate extensibility. To that end, Implementations MUST preserve unrecognized properties and their associated values.
Another specification [LINK_TBD] explains how to extend the parameters used with this API using JSON-LD.

ISSUE XYZ: The Working Group seeks feedback from the Web community on that specification and how well it furthers interoperability needs in the payments ecosystem. To provide feedback, see the status section above.
"""

@adrianba
Copy link
Contributor

How can you tell if an implementation preserved unrecognised values or not? What would a test for this look like?

@halindrome
Copy link
Contributor

Ahh! As it turns out I have been working on this. It is pretty straightforward. We will supply a skeletal payment app that communicates with the test management system's server. Custom code on the server will evaluate the messages that are passed to the payment app from the user agent to ensure the messages adhere to the structure that was input. So we can evaluate the basic parameters, and also ensure that the data passed through is untouched.

A separate communication channel from the test case to the server (web sockets and service worker) will send /down/ the success criteria, and will receive /up/ a message from the server indicating the success or failure of the evaluation.

@msporny
Copy link
Member Author

msporny commented Mar 17, 2016

+1 @halindrome - that's how we've tested stuff like this in the past via our JSON-LD tests (and it is pretty simple to test).

@mattsaxon mattsaxon added this to the Priority: High milestone Mar 21, 2016
@adrianhopebailie adrianhopebailie modified the milestones: Priority: Medium, Priority: High Apr 19, 2016
@adrianhopebailie adrianhopebailie modified the milestone: Priority: Medium Apr 22, 2016
@adrianhopebailie
Copy link
Collaborator

The mechanism for data in a PaymentRequest to be extended is through payment method specific data.

@msporny
Copy link
Member Author

msporny commented Jun 16, 2016

There is still no section on extensibility in the specification. -1 on closing this issue.

@adrianhopebailie
Copy link
Collaborator

@msporny I believe that this will be captured in the Payment Method Identifiers spec so this list is not the right place for this issue.

If you disagree and have some text you consider appropriate for this spec please submit a PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants