Re: Digest for opentransact@googlegroups.com - 6 Messages in 2 Topics
Hugh Barnard
First of all thanks to everyone who's working currently on this,
you're the giants upon whose shoulders I'll stand.
Just some general comments on the discussion, that may hopefully make
some of the controversies tidier and more manageable.
Many years ago, when dinosaurs walked the earth, I grew up with:
http://en.wikipedia.org/wiki/OSI_model, a seven layer communications
model that has since been superceded by the five layer TCP/IP model.
So, for me, many of the discussions about 'scope' are probably about
clearly defined layering.
This brings me to another point. I've had something that looks a
little like opentransact in Cclite, probably for about a couple of
years. So I'm planning to align with that when I feel that
opentransact is more tightly defined [probably with BNF, but I'm
pretty old-skool] and 'finished' [when is anything ever finished
though?!]. However, I also have gpg encrypted email payment, so that
doesn't fit quite as well into that model, for example and users are
identified/addressed in a different way too.
For me, most of the current discussion is at layer 5 [or layer 7 in
the ISO model] the application layer, but discussions about transport
and topology [especially witrh regard to peer to peer versus, for
example, exchangers or automated clearing houses] feel slightly
'further down' the stack. Hence some of the controversy about scope.
As I work mainly in the alternative/social currency field, I also feel
that some technology decisions/arrangements are not neutral with
respect to governance. For example, I'd probably want social
entrprises to be able to implement a complete stack [local currency
groups and exchangers, say, if that was a topology] even if they
choose afterwards to let someone else do the clearing house bit.
Ok that's enough from me, but as always 'rough consensus and running
code' is never a bad thing. I saw X400:
http://en.wikipedia.org/wiki/X.400 lose out to SMTP in many senses,
mainly because it was over-complex, contained a lot of marginal
use-cases and was designed by a huge number of committees and
conflicting interests.
Best regards Hugh
On 16 January 2012 08:13, <opentr...@googlegroups.com> wrote:
> Today's Topic Summary
>
> Group: http://groups.google.com/group/opentransact/topics
>
> New Editor's Draft for PaySwarm Web API [1 Update]
> My two cents on Definitions [5 Updates]
>
> New Editor's Draft for PaySwarm Web API
>
> Manu Sporny <msp...@digitalbazaar.com> Jan 16 02:00AM -0500
>
> bcc: OpenTransact
>
> There is a new time-stamped editor's draft for the PaySwarm Web API that
> addresses some of the issues that Pelle had with the document:
>
> http://payswarm.com/specs/ED/web-api/2012-01-16/
>
> Based on the discussion last Friday[1], the additions include:
>
> * The Transaction Process and Algorithm[2] - supports Payment Links
> spec (which is basically the OpenTransact payment URL mechanism) and a
> programmatic Web service API for performing very basic decentralized
> payments.
> * The Decentralized Settlement Process[3] - which is used to ensure the
> immediate and smooth transition of funds from an account on one
> authority to an account on another authority.
> * The Data Portability and Authority Migration Algorithm[4] - which
> ensures data portability from one authority to another, helps
> prevent vendor lock-in and uses market forces to ensure that
> authorities are meeting their customer's needs.
> * The Transaction Intents Process and Algorithm[5] - which supports
> things like crowd-funding and other forms of constraint-based
> payments.
>
> Things that still need to be detailed in the spec:
>
> * Access control delegation via digital signatures
> * Purchase routing
> * Currency exchanges and mints
> * Lots of cleanup as the document is incredibly rough
>
> I'm pretty sure that the 23 other features mentioned in the blog post
> are already in the spec in some form, but if anyone thinks differently,
> please let the mailing list know and someone on here would be happy to
> point you to a link.
>
> -- manu
>
> [1] http://payswarm.com/minutes/2012-01-13/
> [2] http://payswarm.com/specs/ED/web-api/2012-01-16/#the-transaction-process
> [3]
> http://payswarm.com/specs/ED/web-api/2012-01-16/#the-decentralized-settlement-process
> [4]
> http://payswarm.com/specs/ED/web-api/2012-01-16/#the-authority-migration-algorithm
> [5]
> http://payswarm.com/specs/ED/web-api/2012-01-16/#the-transaction-intent-process
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: PaySwarm vs. OpenTransact Shootout
> http://manu.sporny.org/2011/web-payments-comparison/
>
>
>
> My two cents on Definitions
>
> Pelle Braendgaard <pe...@stakeventures.com> Jan 15 01:43PM -0500
>
> Very interesting and a many similarities of course with OpenTransact.
>
> I've been thinking that we are missing a "status" field as to allow
> something like the "approved", "rejected" etc as you mention.
>
> About the verification methods. OAuth 2 itself right now is about
> Authorizing tokens and the the actual authentication is handled by various
> separate specs such as:
>
> http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-15.html Which is
> what most people think of as OAuth 2
>
> http://tools.ietf.org/html/ietf-oauth-v2-http-mac-00 uses HMAC signing but
> could easily be extended with RSA signing if need be.
>
> I think though most providers will stick with the bearer tokens. An
> institution could in theory require rsa for larger values.
>
> I do agree that the interop is important. I just think it shouldn't be a
> requirement. For example the idea with OpenTransact is that it can be used
> for many different types of assets, not just denominated in national
> currencies. Forcing interop in the way Manu discusses it would severely
> limit the scope of the standard.
>
> I will write up the recipe shortly for this and after feedback propose an
> open transact-federated spec for dealing with it.
>
> P
>
>
>
> --
> http://picomoney.com - Like money, just smaller
> http://stakeventures.com - My blog about startups and agile banking
>
>
>
> Pelle Braendgaard <pe...@stakeventures.com> Jan 15 01:47PM -0500
>
> It would be interesting if someone could come up with an OpenTransact/ISO
> bridge.
>
> Obviously there would have to be some kind of mapping between public
> account urls and what is used with ACH.
>
> How do you handle account mapping now? Can your customers pay using routing
> and account numbers?
>
> P
>
>
> --
> http://picomoney.com - Like money, just smaller
> http://stakeventures.com - My blog about startups and agile banking
>
>
>
> Tom Brown <herestomwit...@gmail.com> Jan 15 01:21PM -0600
>
> it's nice to see a constructive thread again. is there a primary motivation
> for producing a federated spec right now? correct me if i'm wrong, but
> this seems to be related to friday's teleconference. i listened to the
> teleconference and it seems it can reasonably be characterized as a series
> of undefined accusations against the opentransact spec. it's
> "centralized", "not interoperable" and by the end "it doesn't scale". if
> there's no agreement on what centralized, interoperable and scalability
> mean, these accusations are meaningless.
>
> at IIW, all participants are allowed to add a meeting proposal on the
> agenda wall. by "the law of two feet", if you don't think the meeting is
> worth your time, you simply get up and leave it for another. i'm not
> saying conversations about the spec should happen at IIW, but i'm saying
> that i prefer the process under which the opentransact spec is developing
> where people are allowed to vote with their feet.
>
> cheers,
> tom
>
> On Sun, Jan 15, 2012 at 12:43 PM, Pelle Braendgaard <pe...@stakeventures.com
>
>
>
> Alan DeRossett <al...@instapayment.com> Jan 15 01:30PM -0800
>
> The Current ACH transaction system is the problem right now Banks only
> do Batch processing of ACH trasactions. Many of their systems are
> designed to produce the most possible chaos from an accounting
> standpoint. You may not get a reject on an ACH transaction till up to
> four days later. This ensures that banks are never liable and the
> account holder is. Rejected ACH transactions are subject to Charges on
> both ends by banks. A real time reject or denied response would prevent
> Banks from earning overdrafts. With ACH you will need a "Status" field.
> The open transact /ISO bridge could be set up on a simple linux system.
> Jpos.org provides an in expensive comerical deployment or just download
> it yourself.
> from jpos.org
> "In addition to XML, we can extend ISO/Bridge in order to interface
> with your SQL database, message oriented middleware or just setup a
> filesystem based message exchange."
>
> Alan DeRossett
> InstaPayment
>
> On 1/15/12 10:47 AM, Pelle Braendgaard wrote:
>
>
>
> Alan DeRossett <al...@instapayment.com> Jan 15 02:26PM -0800
>
> Types of Tax supported?
> I was wondering if OpenTransact or Payswarm provides the VAT fiscal
> device support that's required on purchases in the EU for VAT registered
> traders or Vat Fiscal devices like receipt printers. The specs are part
> of a POS transaction from most Unified POS systems.
> Payments must be recorded for VAT and electronic Tax payments made for
> each sale. I know the US is working on their own version of collecting
> directly at the point of sale or ATM. Several US states have already
> started to demand sales Tax be paid from each transaction online,
> Amazon.com is currently being assessed.
> The Streamlined Sales Tax Amnesty Program is suppose to automate the
> collection from internet sales Tax for all 5400 different tax
> districts. Systems will need to charge the appropriate sales tax based
> on a customers location and pay immediately to the local tax authority.
> An Audit trail is also required.
>
>
> Vat Fiscal Receipts
> http://hapatwa.com/efd.php
> MS
> http://msdn.microsoft.com/en-us/library/microsoft.pointofservice.fiscalprinter(v=winembedded.1002).aspx
> Streamlined Sales Tax
> Malta
> http://www.vat.gov.mt/fiscalreceiptbooks.aspx
> US State Sale Tax
> http://www.streamlinedsalestax.org/
>
> Alan DeRossett
> InstaPayment
>
>
>
> You received this message because you are subscribed to the Google Group
> opentransact.
> You can post via email.
> To unsubscribe from this group, send an empty message.
> For more options, visit this group.
--
http://www.hughbarnard.org
http://www.twitter.com/hughbarnard
http://www.big-wave-heuristics.com/
http://www.hackney-environment-network.org.uk/