web-payments / web-payments.org Goto Github PK

Hello,

In this default test you use another date (from this page) for generate signature. Please, change the string to sign:
date: Thu, 05 Jan 2012 21:31:40 GMT

A standard config file format should be created for PaySwarm clients so that they can share information between implementations. The configuration file format should be expressed in JSON-LD, which is readable by any JSON library. There is a specific format for entries and all applications that read and write data to the configuration file MUST do so in a standard way.

In Unix-based environments, the configuration file should be stored in the directory specified by $XDG_CONFIG_HOME/payswarm1/default or default to ~/.config/payswarm1/default. The $XDG_ prefix is used by the Freedesktop project.

Additional config files may be specified by name for different PaySwarm configurations. For example, the development configuration can be used by doing the following:

"payswarm -c dev ..."

If $XDG_CONFIG_HOME is set, the file that is read should be $XDG_CONFIG_HOME/.config/payswarm1/dev
If $XDG_CONFIG_HOME is not set, the application should look for that file in: ~/.config/payswarm1/dev

The configuration should use the following config file template:

{
  "@context": "https://w3id.org/payswarm/v1",
  "publicKey": {
    "publicKeyPem": "-----BEGIN PUBLIC KEY-----... -----END PUBLIC KEY-----",
    "privateKeyPem": "-----BEGIN RSA PRIVATE KEY-----...-----END RSA PRIVATE KEY-----",
    "id": "https://dev.payswarm.com/i/CUSTOMER/keys/NUMBER"
  },
  "owner": "https://dev.payswarm.com/i/CUSTOMER",
  "source": "https://dev.payswarm.com/i/CUSTOMER/accounts/ACCOUNT"
}

When a configuration file is stored to disk by any PaySwarm client, it MUST be done using the template above and pretty-printed with 2-space indentation.

The source commerce vocab specs/source/vocabs/commerce.html defines the vs: prefix as http://www.w3.org/2003/06/sw-vocab-status/ns#. However, the ED commerce docs specs/ED/vocabs/commerce/2014-10-11/index.* all use vs:term_status but never define vs:.

We should elaborate on the requirement for payment processors to cache the JSON-LD contexts used for performing financial transfer (or any sort of operation that has legal ramifications or could be used for theft if corrupted).

Manu Sporny wrote:

Talking specifically about the PaySwarm JSON-LD context, it will always
be built into the software due to attack vectors through the JSON-LD
context if the w3id.org website or the web-payments.org website were to
ever be compromised. It's possible to reverse transactions by switching
the meaning of "source" and "destination" in a PaySwarm transaction. To
protect against that attack, PaySwarm payment processor software always
uses local, verified, up-to-date copies of all JSON-LD contexts used for
financial transaction purposes.
Elf Pavlik wrote:
Very interesting! Does it stand somewhere in 'Security Considerations' of one of Web Payments specs? Might make sense to put it somewhere around: https://web-payments.org/specs/source/web-payments/#the-transaction-algorithm

The discussion started here: http://lists.w3.org/Archives/Public/public-webpayments/2013Dec/0098.html

Feedback by @bshambaugh on 10/9/2014 11:31:22:

Do you have feedback on the Legacy Support design criteria?

This is a great idea!

Do you have feedback on the Data Portability design criteria?

This is a great idea!

Do you have feedback on the Web Intents / Protocol Handlers design criteria?

Not right now.

Do you have feedback on the Authorization Configurability design criteria?

Agreed.

Do you have feedback on the Smart Contracts design criteria?

Agreed.

Do you have feedback on the Physical Receipts design criteria?

Agreed.

Is there design criteria that you feel is missing from the document?

Not right now.

Do you have any feedback on the Purchase Request use case?

Not right now.

Do you have any feedback on the Payment Links use case?

Not right now.

Do you have any feedback on the Choice of Payment Processor use case?

No NASCAR problem?

Do you have any feedback on the Parametric Offers use case?

How is this queried?

Do you have any feedback on the Coupons and Loyalty Cards use case?

Not right now.

Do you have any feedback on the Pseudo-anonymity use case?

Various identities? Need to check.

Do you have any feedback on the Transaction Fee Optimization use case?

Good idea!

Do you have any feedback on the Choosing the Attributes of Price use case?

Good idea!

Do you have any feedback on the App-store Purchases use case?

Not now.

Do you have any feedback on the In-App Purchases use case?

Not now.

Do you have any feedback on the Payment Tokenization use case?

Good idea!

Do you have any feedback on the Registration-less Purchases use case?

Good idea!

Do you have any feedback on the Push-based Payments use case?

Not now.

Do you have any feedback on the Subscriptions use case?

Not now.

Do you have any feedback on the Non-interactive Purchases use case?

Not now.

Do you have any feedback on the Digital Wallet Portability use case?

Not now.

Do you have any feedback on the Realtime Regulatory Reporting use case?

Good idea!

Do you have any feedback on the Digital Receipts use case?

Not now.

Are there use cases that you feel are missing from the document?

Not now.

We need to complete a full STRIDE threat analysis on the HTTP Signatures specification and write up the findings in a separate document. We probably want to publish this as another IETF draft, as security analysis can lead to reams and reams of words written and we don't want to give people the mistaken impression that HTTP Signatures are complicated by expanding it into an 80 page document, where 70 of those pages are threat analysis.

We should write a Security Considerations section, following all the attack vectors outlined in RFC 3552.

We may also want to consider the guidance given in RFC 4104.

We will also want to use terminology from RFC 4949.

/cc @mcavage

Disclaimer: I'm new here 😉

It looks like to add EcdsaKoblitzSignature2016 (coming soon once https://github.com/w3c-dvcg/lds-koblitz2016/pull/4 is merged) to https://web-payments.org/contexts/security-v1.jsonld we would add a line to that context like this:

    "GraphSignature2012": "sec:GraphSignature2012",
    "LinkedDataSignature2015": "sec:LinkedDataSignature2015",
    "LinkedDataSignature2016": "sec:LinkedDataSignature2016",
+    "EcdsaKoblitzSignature2016": "sec:EcdsaKoblitzSignature2016",
    "CryptographicKey": "sec:Key",

And then add a new section for EcdsaKoblitzSignature2016, linked to by https://web-payments.org/vocabs/security#EcdsaKoblitzSignature2016, directly after the existing LinkedDataSignature2016 section.

Sound about right?

Tagging @msporny 🆘

I already tried notifying about it over mailing list: http://lists.w3.org/Archives/Public/public-webpayments/2013Dec/0098.html

$ curl -IL https://w3id.org/payswarm/v1
HTTP/1.1 302 Found
Date: Tue, 31 Dec 2013 17:13:30 GMT
Server: Apache/2.2.22 (Ubuntu)
Access-Control-Allow-Origin: *
Location: https://payswarm.com/contexts/payswarm-v1.jsonld
Vary: Accept-Encoding
Content-Type: text/html; charset=iso-8859-1

HTTP/1.1 301 Moved Permanently
date: Tue, 31 Dec 2013 17:19:25 GMT
server: Apache/2.2.22 (Ubuntu)
location: http://web-payments.org/contexts/payswarm-v1.jsonld
vary: Accept-Encoding
keep-alive: timeout=5, max=100
connection: close
content-type: text/html; charset=iso-8859-1

HTTP/1.1 302 Moved Temporarily
date: Tue, 31 Dec 2013 17:13:54 GMT
server: Apache/2.2.22 (Ubuntu)
location: https://web-payments.org/contexts/payswarm-v1.jsonld
vary: Accept-Encoding
keep-alive: timeout=5, max=100
connection: close
content-type: text/html; charset=iso-8859-1

HTTP/1.1 500 Internal Server Error
date: Tue, 31 Dec 2013 17:13:55 GMT
server: Apache/2.2.22 (Ubuntu)
vary: Accept-Encoding
connection: close
content-type: text/html; charset=iso-8859-1

Feedback by @daustin2011 on 10/6/2014 11:25:52:

Do you have feedback on the Legacy Support design criteria?

This set of requirements is necessary for this group's work to be successful. It should however be entirely re-framed in terms of language and intent:

• The requirement should be that any stands proposed should enhance the existing payment systems - not 'legacy' but current. Without the support and participation of these organizations, we will fail. The IETF is a graveyard of failed payments -related standards, which were rejected by the financial community.
• We need to avoid any sort of presuppositions about the design here - terms like abstraction layer are (hypothetical) solutions, not problems to be solved. Keep the requirements simple and free of technical assumptions.
• We're not in the policy business, we're here to solve problems for the existing financial community. This means that we don't have a position on the outcome, beyond meeting requirements. We're not overturning the World order or leading the revolution in payments. Our goal is to make things inter-operable in a complex world, not to promote any particular POV.

Do you have feedback on the Data Portability design criteria?

Buzzwords. What does this mean?

Do you have feedback on the Web Intents / Protocol Handlers design criteria?

This sounds like a plea for a specific technology/design pattern. I'm sympathetic in this particular case but again, we MUST NOT presuppose solutions or technologies. Web intents are great. We'll consider them along with everything else. But there's no requirement here, and it probably doesn't belong in this document.

Do you have feedback on the Authorization Configurability design criteria?

This stepwise authorization is common in the US, and is already widely implemented. Does this need standardization? It seems like a product feature. Each organization will want to have their own authorization mechanism based on context, history, and their perceived risk. I think our requirement should be that we create systems that don't preclude this, or that support existing mechanisms or improve them. Having this feature isn't a requirement.

Do you have feedback on the Smart Contracts design criteria?

It sounds good - but what does it mean? Can you provide an example? Which areas of standardization are most important right now, as this technology (and the associated social systems) are being developed? Again, I think we should develop standards that don't preclude this, without restricting future developments.

Do you have feedback on the Physical Receipts design criteria?

This sounds good, it's definitely a requirement in the sense that if we developed standards that didn't allow this it would result in failure.

Is there design criteria that you feel is missing from the document?

• need to mention online/offline transactions and how to handle them
• need to handle escrow use cases
• use cases should use standard template (Cockburn et all)

Do you have any feedback on the Purchase Request use case?

TBD - more later

It's currently very difficult for readers to understand the basic PaySwarm payment flow for the purchase of an item online. A graphical depiction of the buy flow would help alleviate some of this problem.

The conversation that triggered this issue is here: http://lists.w3.org/Archives/Public/public-webpayments/2014Jan/0039.html

Some of the works herein are carried on by other W3C groups, hence, consider updating spec URLs to use latest URLs or mention of latest URLs, eg:

https://web-payments.org/vocabs/security
->
https://w3c-ccg.github.io/security-vocab/

Melvin Carvalho noted that it's difficult to understand the differences between the two .well-known endpoints that PaySwarm uses:

http://lists.w3.org/Archives/Public/public-webpayments/2012Aug/0009.html

While this was meant to separate spec concerns between Web Payments and Web Keys, it is not immediately apparent why we need two files. It may be more pure from a design standpoint... but some people may not care and may just want to have the Web Keys endpoint expressed in /.well-known/payswarm since PaySwarm needs it anyway.

Placing it in one file would reduce the number of overall HTTP requests from PaySwarm clients. We can still keep the old /.well-known/web-keys file around, but move its services into /.well-known/payswarm?

Review by James Manger uncovered the following issues:

1. Content-Length in the example in section 2.1.2. "Signature String Construction" should be 14, not 15. The content-MD5 value is calculated over 14 bytes.
2. The string to be signed (section 2.1.2. "Signature String Construction") looks like lines that could be sent in the HTTP request, but they donât quite match. Lines in an HTTP header end with \r\n, whereas lines in the string to be signed end in \n. Why bother omitting \n from the last line? It is simpler to end all the lines the same way. It is annoyingly awkward to write files with a text editor that omit a final \n.
3. The signature is wrong in section 4.1. "Default Test". Unpacking the signature reveals a SHA-256 hash of EBF002A95EC4DDB7A50CCAC009BAA2FE5D1B2604DA7CB871B870CEE21BE85EB9. The SHA-256 has of "date: Thu, 05 Jan 2012 21:31:40 GMT" is 1958B656C09E29824A2BCF03197923BCD9B55370F2FF2118FF4C47AD77513B3F.
4. The signature is wrong in section 4.2. "All Headers Test". Unpacking the signature reveals a SHA-256 hash of 4E7A038BC9EFAB95AC829AC176659DCE0A7B6DC94F9FAA54375390A5EA8A9B37. The SHA-256 has of all the headers is 1015528C71F9BC3D445B457CA41D8BC884E89275EDDD0F0435BBB13A65B4550D.
5. The fields that are signed are absolutely crucial in determining the security properties achieved. It is not sufficient for the spec to merely say the choice of fields is "out of scope" in a clause of the "Security Considerations" (section 3.5 "Required Headers to Sign").
6. The introduction needs to state that: the mechanism signs a subset of an HTTP request; recipients need to be pre-configured with the subset they require (and MUST confirm that "headers" includes at least that subset); the body is only protected if a Content-MD5/Digest is signed (and the body hash is checked). Signing just "date" show the originator committed to one HTTP request at about the time of the date value, but gives no protection as to the nature of that request (the query params, path, method, body, or even host etc). One strategy for recipients would be to only pass signed fields on to the next stage of request processing.

From Kingsley Idehen:

Bearing in mind that WebID is a totally separate thing from the WebID + TLS authentication protocol, I don't see why "Web Identity 1.0" can't adopt the same notion of a WebID which is already established.

Adopting my suggestion will not change "Web Identity 1.0" per se., we simply end up with:

identifier
An HTTP URI that denotes an entity.

identity card
Information that can be used to identify a particular entity such as a person, animal, or organization.

identity card owner
An entity that is in control of a particular identity card.

identity card provider (or host)
A website providing access to an identity or set of identities.

requestor
A user agent that is requesting to access and/or modify an identity.

Reference to source discussion: https://plus.google.com/+ManuSporny/posts/94fooRHDb6T

There's no information about what the identity provider can display to the identity owner to indicate who they are providing access to their information to via the POST callback method.

There needs to be some description of what information the IDP can use to display to the IDO. The HTTP signature part should probably also touch on this by indicating that the key needs to be tied to an identity that can be read with information that can be displayed to the IDO in other words, this protocol needs to specify how information can be shown to the IDO so they can make an informed decision about whether or not they should let their info be given out.

From Ade Oshineye:

There is no indication that other solutions were considered or that extending technologies like OpenID Connect was considered.

From Elf Pavlik:

Mozilla Open Badges and http://webfinger.net should be considered

We may not want to put this in the spec, but rather in a blog post since the information will quickly become outdated.

Reference to source discussion: https://plus.google.com/+ManuSporny/posts/94fooRHDb6T

Feedback by Pindar Wong on 9/26/2014 18:51:08:

Are there use cases that you feel are missing from the document?

Perhaps consider whether any escrow cases should be included.

Daniel Austin wrote:

My colleagues here at eBay became aware of this site (web-payments.org) and are expressing some concern:

The rest of the email thread can be found here:

http://lists.w3.org/Archives/Public/public-webpayments/2014Jan/0061.html

After discussing with W3C, the following modifications could be made to the website to address some of the messaging concerns:

• Attempt to clearly specify that the CG is not endorsed by the W3C, but it is also designed to create material that may be fed into W3C or other standardization bodies like the IETF.
• Make a clear statement that although this work is not yet on the W3C recommendation track, as it matures, the community will evaluate whether or not they want to petition W3C to elevate it to the standards track.
• Specify that the "Who" is a community that wants to build payments into the core architecture of the Web.
• Remove "ailing financial infrastructure" statement at top of page with something more upbeat.
• Specify liason groups that the community will engage while performing the work.
• Create a page for a charter for the group.

http://lists.w3.org/Archives/Public/public-webpayments/2014Oct/0182.html

Here are a couple of possibilities combining the international standard generic symbol for currency: http://en.wikipedia.org/wiki/Currency_%28typography%29 with the de facto Internet communications symbol @:

~joseph

From Ade Oshineye:

I'd like to see something in the spec explaining how this differs from the Claims section of OpenIDConnect: http://openid.net/specs/openid-connect-core-1_0.html#Claims

We should also do a comparison between Web Identity and WebFinger.

Reference to source discussion: https://plus.google.com/+ManuSporny/posts/94fooRHDb6T

Feedback by jfaisca on 10/9/2014 8:08:04:

Do you have feedback on the Data Portability design criteria?

Pay attention to SAF-T (Standard Audit File for Tax), an international standard for electronic exchange of reliable accounting data from organizations to a national tax authority or external auditors. The standard is defined by the OECD (Organisation for Economic Co-operation and Development). The file format is based on XML.

http://www.oecd.org/ctp/administration/34910263.pdf

identity-v1.jsonld#L3-L9

{
  "@context": {
    "id": "@id",
    "type": "@type",

    "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
    "sec": "https://w3id.org/security#",
    "id": "https://w3id.org/identity#",
    ...
  }
}

Remove PUT and DELETE until someone requests that it be in there.

From a review of the HTTP Signature Auth Scheme by @mnot:

You don't define a corresponding challenge. Your use cases might not require a 401 + WWW-Authenticate, but have you considered that some will want this?

From @msporny:

Yes, we did consider it. We wanted this to be a mostly "you're verified or you're not" mechanism. We didn't really want any sort of back-and-forth negotiation. That said, it's a weak argument because you probably want to be able to notify clients that they could access the resource if they provided a signature. If we decide that this is going to use the "Authorization" header (and not some new kind of header), we'll define the WWW-Authenticate bits of it.

The rest of the thread can be found here: http://lists.w3.org/Archives/Public/public-webpayments/2014Feb/0019.html

Feedback by @erickorb on 9/26/2014 18:15:56:

Is there design criteria that you feel is missing from the document?

3rd-payee payees? Someone paying on behalf of another?

According to the main docs, the Domain for com:Cumulative is com:rateType, however the example has "com:rateType" : "com:ExclusivePercentage" and "com:rateContext": "com:Cumulative" in the following file:

specs/ED/vocabs/commerce/2011-12-13/index.html

I don't know which is correct.

Feedback by Darien Brown on 10/2/2014 1:26:31:

Is there design criteria that you feel is missing from the document?

There is no mention of returns / credits. This is important when considering payment tokenization, payment links and alternative forms of payment. One must also consider uneven exchanges - where a buyer returns a product to exchange for one more expensive and the merchant must collect the difference.

The draft report at https://web-payments.org/vocabs/security is still using the security/v1 vocabulary, and has been updated last time in April 2016. This should probably be updated so that it would document the security/v2 vocabulary and it's new proof, proofPurpose and proofValue variables.

Feedback by Adrian Hope-Bailie on 10/1/2014 9:57:17:

Do you have feedback on the Legacy Support design criteria?

This will be essential as a bridge from the old to the new. It is expected that providing this bridge will be seen as a significant commercial opportunity for incumbents so it will be important to consider motivating factors for these incumbents to adopt an open standard.

Put another way it would be useful if there were other ways incumbents could protect their commercial interests while still adopting open payments standards.

Do you have any feedback on the Coupons and Loyalty Cards use case?

Would this be considered a tender type or is it more complex than this?

Do you have any feedback on the Choosing the Attributes of Price use case?

I don't think the value-in-exchange benchmark is necessary. This falls into the scope of smart contracts. For web payments we should assume all transaction details are finalised at the time of processing.

If a seller/payee wishes to offer multiple payment options in multiple currencies this should be explicit so the payer can simply pick the one they favour.

Do you have any feedback on the Push-based Payments use case?

It should be possible for a buyer to complete this flow without the payment processor knowing who the payment is going to (if the payment mechanism supports this). i.e. Payment could be to a psuedo-anonymous payee identifier

Cyrus Daboo said that the HTTP Signatures spec is like the approach taken for iSchedule. We should do an analysis on DKIM to outline why that solution isn't appropriate for HTTP-based signatures.

Namely, we may want to state that domain-based keys are not the point, we want agent-based keys. That said, we may be able to re-use the signing portions of DKIM in the HTTP Signatures spec.

Ade Oshineye wrote:

I'd also like to see this spec explain how it's going to play well with a world of mobile devices that have identity baked into them.

Reference to source discussion: https://plus.google.com/+ManuSporny/posts/94fooRHDb6T

The HTTP Signatures 1.0 spec should probably explain exactly how to implement nonces for implementers that would like a fully vetted solution that protects against replay. This would be useful for implementers implementing HTTP signatures in a clear channel environment.

Another consideration for nonces is the probability that multiple clients may share the same public key. In this instance, due to clock skew issues, it is possible that some clients may accidentally trigger replay protection by sending a date in the past. The balance that this spec attempts to achieve is a simple per-client, time-based counter. Thus, the nonce would need to include something like a UUID-based client identifier, plus an incredibly accurate UTC datetime-based nonce as described in RFC 3339 [RFC3339]. For example: "598ef3e8-98b0-435d-8ca3-fecefdd87568 2013-
05-04 20:00:35.808785840+00:00"

Feedback by Steven Rowat on 9/26/2014 19:56:18:

Do you have any feedback on the Coupons and Loyalty Cards use case?

Put off until version 2.0

When a vendor lists their product for sale, they should be able to list multiple currencies that are accepted for the sale. They should also be able to specify multiple pricing algorithms so that prices track vendor-chosen indexes, such as the current trading price for gold, oil, or a basket of commodities.

More background can be found here:

http://lists.w3.org/Archives/Public/public-webpayments/2013Oct/0108.html

Feedback by Evgenii Vinogadov on 10/2/2014 4:39:01:

Do you have any feedback on the Pseudo-anonymity use case?

It sounds not very clear, and it is better to clarify the meaning of "variable degrees of pseudo-anonymity" (at least with examples of levels and parties).

Do you have any feedback on the Realtime Regulatory Reporting use case?

I think that we should remove "real-time" word here. Reporting can be fast, but not need to be completed before transaction ends.

Should one consider sec:owner and sec:publicKey as inverse properties?
Linked Data Signatures Verification Algorithm states:

Confirm that the Linked Data Document that describes the public key specifies its owner and that its owner's URL identifier can be dereferenced to reveal a bi-directional link back to the key

If sec:publicKey doesn't work as inverse of sec:owner, i would prefer to just use sec:owner in reverse direction and not use sec:publicKey all together.

I can find security vocabulary html spec
https://web-payments.org/vocabs/security

And JSON-LD context
https://w3id.org/security/v1

I can't find RDFS/OWL documents which could provide statements like owl:inverseOf

The Key class allows PEM-encoded public keys (example from specification at the end). Do we envision this class being extended to handle public keys formatted as in the Linked Data Koblitz spec?

E.g. "creator": "ecdsa-koblitz-pubkey:..."

{
  "@context": "https://w3id.org/security/v1",
  "@id": "https://payswarm.example.com/i/bob/keys/1",
  "@type": "Key",
  "created": "2012-01-03T14:34:57+0000",
  "revoked": "2012-05-01T18:11:19+0000",
  "owner": "https://payswarm.example.com/i/bob",
  "publicKeyPem": "-----BEGIN PRIVATE KEY-----\nMIIBG0BA...OClDQAB\n-----END PRIVATE KEY-----\n",
}

The current /.well-known/web-keys returns this:

{
  "@context": "http://purl.org/payswarm/v1",
  "publicKeyService": "https://dev.payswarm.com/i?form=register"
}

When it really should return this (note the change in @context):

{
  "@context": "http://purl.org/web-keys/v1",
  "publicKeyService": "https://dev.payswarm.com/i?form=register"
}