Validation of values that may contain more than one item

[msporny]

Should validation of a payment message throw an error if the value is not an array (even if that array only has one item in it).

For example, acceptablePayment may take one or more acceptable payment methods as it's value. So, the value could be either an object or an array. Should we say that the value MUST always be an array containing one or more acceptable payment methods in the JSON Schema? Or should we allow it to be either an object or an array. If it's an object, assume that there is only one acceptable payment method.

[scanon56]

Manu, I think it must be an array. I also assume that the LD principles are followed and it will be an array of URIs ?

[msporny]

I also assume that the LD principles are followed and it will be an array of URIs ?

For the JSON-LD serialization of the message, the short answer is "yes".

The long answer is that each item in acceptablePayment could be either a blank node or a URL-identified resource, which could have a number of properties associated with it. In JSON-LD, paymentRequest would show up as an array of objects. For an example of what to expect, look at the following:

http://w3c.github.io/webpayments-core-messages/#paymentrequest

[scanon56]

I’ve been developing ISO20022 for SWIFT and among other things, the payment messages that are used for SEPA payments (EURO payment across European Community). Reinventing messages without « Linked Data » does not make sense.

An ISO20022 international payment message is composed of about 1000 data elements. There are, for example, multiple name and addresses and the regulation (FATF) imposes to carry the name and address of both the payer and the payee. It means that the payer needs to know the name and address of the payee. All banks in the settlement chain need to carry this information. Overall, the industry is spending millions for theses name and addresses. However, you can make payment to Mickey or Donald and give a fake address, some banks might check if the address is real but no bank can check it is related to the name and/or the account. Even the beneficiary bank is not checking the link between the name and the account. This is a well known source of fraud in all countries: it suffices to replace the account number and keep the original name and address, the payment will go to the account.

So, we have an expensive, inefficient system. Making the same kind of payments on the Web wouldn't help. The opportunity is instead to use the web to fix problems we were not able to fix before, eg. use URIs to « universal data stores » where data is controlled and protected. To me, « Linked Data » is a pre-requisite to any significant innovations in the financial industry: without standardisation of data, it doesn’t help to have a distributed ledger. Sharing a ledger implies all sharing parties have the same definition of the assets and parties on the ledger.

Stephane

Le 8 mai 2016 à 19:16, Manu Sporny notifications@github.com a écrit :

I also assume that the LD principles are followed and it will be an array of URIs ?

For the JSON-LD serialization of the message, the short answer is "yes".

The long answer is that each item in acceptablePayment could be either a blank node or a URL-identified resource, which could have a number of properties associated with it. In JSON-LD, paymentRequest would show up as an array of objects. For an example of what to expect, look at the following:

http://w3c.github.io/webpayments-core-messages/#paymentrequest http://w3c.github.io/webpayments-core-messages/#paymentrequest — You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/w3c/webpayments-core-messages/issues/3#issuecomment-217734319

[msporny]

To me, Linked Data is a pre-requisite to any significant innovations in the financial industry

I am in 100% agreement with you, Stephane. The problem is that the browser vendors are not interested in supporting Linked Data, so they would push back heavily against a proposal that contained Linked Data. I think the best we can do is define a way of expressing these messages as Linked Data that is also compatible w/ the non-Linked Data messages processed via the browser. JSON-LD enables us to do this, and the Core Messages and HTTP API specifications are designed to support this approach as well.

I hope you'll let the rest of the Web Payments Working Group know your position on this as they are not very familiar with Linked Data and have not heard many financial institutions say what you've said above. They need to hear from people like yourself.

[adrianhopebailie]

I hope you'll let the rest of the Web Payments Working Group know your position on this as they are not very familiar with Linked Data and have not heard many financial institutions say what you've said above. They need to hear from people like yourself.

+1

On 9 May 2016 at 17:06, Manu Sporny notifications@github.com wrote:

To me, Linked Data is a pre-requisite to any significant innovations in the financial industry

I am in 100% agreement with you, Stephane. The problem is that the browser vendors are not interested in supporting Linked Data, so they would push back heavily against a proposal that contained Linked Data. I think the best we can do is define a way of expressing these messages as Linked Data that is also compatible w/ the non-Linked Data messages processed via the browser. JSON-LD enables us to do this, and the Core Messages and HTTP API specifications are designed to support this as well.

I hope you'll let the rest of the Web Payments Working Group know your position on this as they are not very familiar with Linked Data and have not heard many financial institutions say what you've said above. They need to hear from people like yourself.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/w3c/webpayments-core-messages/issues/3#issuecomment-217909301