Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27)


> I do think we should consider an attribute such as "custom" and require the processor to
leave custom data untouched.

I strongly recommend against trying to stuff everything we haven't thought of into a box marked "custom". There are a lot of things I haven't thought of. Instead, let's specify what we have thought of and leave the rest alone.

Furthermore, I think we should be specific about a best practice for extending: i.e. let's specify an extension mechanism that is machine-readable, has decentralized, self-discoverable semantics, has a syntax that already works as regular JSON, and is a W3C Recommendation: JSON-LD. We can be clear about how people ought to interpret messages as JSON-LD -- should they be interested in using this mechanism. If they aren't, that's fine too.

I realize this work is phased and we're trying to keep things narrowly scoped. That doesn't mean we shouldn't be clear about how to extend things so we can get to the future we want in later phases and beyond. For example, I'm imagining a future where people could publish payment request messages (or "offers") on websites using JSON-LD. Then search engines could consume this machine-readable data (Google is already doing this with JSON-LD). Then people could search for what they're looking for and click it -- which would drop that message right into the Browser API and they could complete their purchase.

They could similarly drop that same message into an app that uses the HTTP API and send it where it needs to go. Or into some other API. The point is that you can use the same message across many APIs and you can get these messages in a variety of different ways.

I think it's important that we provide some guidance on how this can be done -- even if that's an extremely minimal amount of guidance during Phase I, i.e. there's a "default" context for people who want to use messages as JSON-LD.

Reply to this email directly or view it on GitHub:

Received on Tuesday, 2 February 2016 23:19:35 UTC