3 ms·
> The aim of this spec is not to exceed 2 pages Then this spec will never be anywhere close to complete. Money isn't just a piece of information that can pass
by striking 10y ago
> The aim of this spec is not to exceed 2 pages
Then this spec will never be anywhere close to complete.
Money isn't just a piece of information that can pass from one place to another. "encryption, workflow, trust and aggregation systems" are not just things you can handwave away.
Who is willing to process transactions like these? Why is encryption and signing not part of the standard?
What happens if I post a credit that is not my own, or with the same @id but differing contents? How much data is exposed by GET /wallet, and will it be a privacy concern?
It's just not helpful.
- blowski 10y agoAgreed. A spec is supposed to be enormously detailed. 2 pages sounds more like a summary blog post.
- colejohnson66 10y agoTo be fair, specs can be short. A wildly used spec that's only 11 pages long (of which only 6 are the actual specification) is RFC 1952[0], the specification of the GZIP file format (.gz) [0]: http://tools.ietf.org/html/rfc1952 http://tools.ietf.org/html/rfc1952
- woah 10y agoThe point of specifications is to standardize certain parts of a system where it interfaces with other systems using the same spec. This looks like it is supposed to pass information from a user interface to a payment system. Specifying the entire system would defeat the point of the specification.
- striking 10y ago> certain parts of a system Implying there is a greater system to speak of. Or even that one has been contemplated. This doesn't fit into any sort of existing payment processing system, nor do the identity systems this is supposed to rest on top of exist.
- norea-armozel 10y agoI agree since you have to deal with various banking systems. In the US this would just be such a mess to support considering ACH (could you do ACH from anything akin to this Web Credits spec?). Bleh this is just a bad idea all around.