New Member Intro - Adrian Hope-Bailie

Hi all,

I am very sorry to have only stumbled upon this group and the work you are
doing now.
I would have liked to be part of the working group in March.

I remember reading up on PaySwarm and OpenTransact about 2 years ago but
didn't have the opportunity at the time to follow the progress of your work
closely.

I am in the process of catching up, many conference call minutes and slide
decks to get through but I think am getting the gist of things.

*A little about me*

I started my career focused mostly on web technology as developer and
architect. In 2008 I joined dotMobi and had some interactions with the W3C
during my time there.

In 2009 I returned to my home country South African and have been involved
in the payments industry since working for a payments software vendor (S1
now ACI Worldwide), a processor and now a payments services company.

About 6 months ago I started my current role which has allowed me the
freedom to explore ideas around payments standards and the Web.

*OpenPayee*

In that time I have been working on what I called the OpenPayee standard,
blissfully unaware of how close much of your work was to what I was working
on.

I started capturing some of my ideas at http://openpayee.org a few weeks
ago.

Based on what I have gathered so far the standards you are developing
address a more vast set of functions than OpenPayee however I believe
OpenPayee still may have a place within this set of standards.

My approach has been slightly different to yours, I think.

Fundamentally I have tried to steer away from the challenges of identity
and privacy of the payer by moving control of the transaction to the payer
and his/her agent/authority and only requiring the payee to provide some
form of identifier and possibly some transaction meta-data.

Using OpenID Connect the payer discovers sufficient information (usually
non-sensitive) about the payee to request a digital invoice, make the
payment and then request a digital receipt. (If someone can direct me to an
explanation of why you believe Open ID Connect is unsuitable as a federated
identity standard, I'd appreciate it).

Key points:

   - In most cases the executing of the OpenID Connect protocol will be
   done by the payer's agent/authority (wallet provider/bank). The transaction
   on his/her smart-phone or web browser by simply processing the payee's
   OpenID identifier. A message must then get to the payer's agent/authority
   that the payer wishes to make a payment to the designated payee. Usually
   this would be done by redirecting the payer's browser to the
   agent/authority's website or launching their app. (Custom URI scheme would
   be ideal but RDF would be sufficient if browsers knew how to handle the
   link type).
   - Once the payer's agent/authority receives the initiation they can
   perform complex discovery and negotiation with the payee or payee's
   agent/authority to decide on the payment method, amount etc. The payer is
   prompted to confirm the terms once a signed digital invoice is presented to
   the payer.
   - The payer's authority then executes the payment via whatever channel
   was agreed. The key here is that this could be some legacy payment channel
   such as a card network or something new like Ripple or Bitcoin. As long as
   the payer and payee both support the channel it's an option.
   - Once the payment is complete the payer agent/authority gets a signed
   digital receipt from the payee or their agent/authority and this is used as
   proof of payment. (It is signed by an entity that the payee trusts)
   - As you will see from some of the use cases this is targeted at non-web
   payments (and even offline payees) too.
   - The standard I am proposing doesn't predicate that the status quo in
   the payments ecosystem changes radically. Where a vendor takes card
   payments via a gateway today, the gateway could simply issue the vendor an
   OpenPayee identifier to use on their website. Customers with OpenPayee
   compatible user-agents would recognise the OpenPayee identifier in the HTML
   of the checkout page or in a link ref on the page and initiate their
   payment via OpenPayee instead of clicking the "Checkout" button. The result
   would be that the payer's agent/auth that has their credit card details on
   record can submit these directly to the gateway and get a signed digital
   receipt from the gateway as proof of payment.

A few things:

   1. I haven't had the chance to capture everything on the website but I
   am working on it. Comments on what is there so far would be much
   appreciated and I will notify this list if I make updates or follow
   @OpenPayee.
   2. If you believe there is merit to the standard and would like to
   incorporate it into your work I am happy for that to happen just let me
   know how I can help.
   3. I have a day-job. As much as I would love to spend all of my time on
   this I run a fairly new business unit in a small company so my time is
   quite precious. I dedicate as much time as I can to this but if someone has
   pointers to save me some time or can assist that would be great.

Looking forward to becoming a very active member of the group.

Adrian