Fwd: Identity in PaySwarm / Persona wishlist (part 1)

--- Begin forwarded message from Manu Sporny ---
From: 
To: Persona Developers <dev-identity@lists.mozilla.org>
Cc: Kumar McMillan <kmcmillan@mozilla.com>
Date: Thu, 04 Apr 2013 18:41:07 +0000
Subject: Identity in PaySwarm / Persona wishlist (part 1)

This is not a set of use cases, but rather the start of a list of things
that we'd like to see in an identity / Web Payments solution. We don't
want tight coupling between identity and payments, but we do want a
really good payments experience. Doing that may mean very deliberate
designing when it comes to how the identity and payments subsystems
communicate in a browser.

For those of you that aren't familiar with the work we're doing at W3C,
here's a link:

http://payswarm.com/

More specifically, we just launched the worlds first commercial
implementation of the Web Payments specs:

http://blog.meritora.com/launch/

The short version of the Web Payments pitch:

A payment solution for the Web should be open and decentralized as much
as possible. It must allow websites to have independent payment
providers from their customers, but ensure that the money flows to where
it needs to go. It must take privacy concerns into account. It must
support very small, low-to-no friction payments (aka: micropayments). It
must work across desktop apps, mobile apps, and Web apps. It must
support multiple currencies, including crypto currencies like Bitcoin.
It must enable decentralized innovation; the messages in the financial
protocol are extensible in order to support different market verticals
(like healthcare, energy, physical retail, web apps, etc.) PaySwarm
supports all of these goals, but there are rough spots that we'd like to
sand down and identity is one of those rough spots.

We, as in Digital Bazaar, the company behind Meritora, would like to
become a Persona idP and augment/get rid of our current identity
solution if possible. If there is going to be an in-browser identity
protocol, we think the payments stuff should utilize it.

Currently, customers on our system are identified by URLs, like so:

https://dev.payswarm.com/i/vendor

A customer can have as many of these identities as they want.

That URL contains machine-readable content in both RDFa 1.1 and JSON-LD.
So, if you do this:

curl -H "application/ld+json" "https://dev.payswarm.com/i/vendor"

you will get back a machine-readable identity, which also lists RSA
public key URLs, which you can dereference and get a public key PEM
from, like so:

curl -H "application/ld+json" "https://dev.payswarm.com/i/vendor/keys/1"

We use this for all digital signatures and encryption on the system.
It's a solution we created called Web Keys (warning: spec horribly out
of date):

https://payswarm.com/specs/source/web-keys/

As you have probably noticed, this is a bit different from the
identifier mechanism used by Persona (an e-mail address). We're fine w/
e-mail address identifiers, there has to be a good way of mapping the
e-mail identifier to the PaySwarm identifier (or some URL-based
identifier which can hold machine-readable data).

The important thing for the protocol is that either:

1. The identity that will be doing purchases on the site will be
transmitted upon login, or
2. The identity that will be doing purchases on the site will be
transmitted when the 'access' content button is clicked.

To do either, /something/ in the browser has to communicate who the
customer's payment processor is. We also need some way of setting the
customer's identity through https://meritora.com/ . The thing that makes
this possible could be either the identity subsystem, or the payments
subsystem.

Which subsystem should it be? It would be nice for the identity
subsystem to be able to transmit other information such as the person's
preferred payment provider upon login (or request). That way, the
payment subsystem could be bootstrapped with information from the
identity subsystem.

That said, the payment subsystem will eventually need to know more
information about the customer, such as the private key used for doing
digital signatures. Other information that may be good to know are
address information, preferred currency, etc. If we assume that the
payments subsystem is already going to need more than just an e-mail
address and preferred payment provider, maybe the place for all of this
is in the payment subsystem, not the identity subsystem.

We also need a way to make sure that the customer can "log out" of a
site and log back in using a different identity and payment provider. It
seems like this should be tied to the identity subsystem. Similarly,
there are times where you just want to do a purchase and don't want to
provide even your e-mail address. PaySwarm currently does not require an
e-mail address for a payment to be made. If we tie this payment stuff to
Persona, we lose that capability, right?

I'll stop here for now and hope to get some responses back before
outlining some other concerns we have with identity and payment.

Have developers on this mailing list tackled this problem yet? Is there
a clear path forward? Is there a plan to more closely integrate Persona
with mozPay() and achieve these sorts of use cases?

-- manu

--- End forwarded message ---

Received on Thursday, 4 April 2013 20:07:36 UTC