Re: The Payment Identity Problem

Hi Eric, Manu

My comments fall more neatly under this thread so I have not responded in
the same thread as you, Eric.
Sorry if this causes confusion but I don't want to pollute the thread about
Identity Credentials.

On 27 June 2014 15:20, Eric Korb <eric.korb@accreditrust.com> wrote:

> At Accreditrust, we are specifically interested in the Identity
> Credentials spec and this particular way of doing things.  Accreditrust
> is addressing the need for associating secure credentials to a long-lived
> identity URL through its TrueCred(TM) Open Credentialing Platform.
>
> We see identity-based credentials to be a critical element of
> web-payments.  We haven't found a situation where an applicant isn't asked
> to provide a form of identity to establish an account with a financial
> institution. (Companies like Experian make millions providing this kind of
> check!) By issuing a digitally signed credentials to an identity
> ("identity-based credentials") such as a driver license, passport, or
> federal identification number, a website could simply request the
> credentials from the web identity.
>
> Once the identity is established, it makes sense to curate other
> high-stakes credentials with it. By way of example, suppose someone was
> applying to a college or take a required skills test.  Once the applicant
> is authenticated with their identity provider, the registration website
> could retrieve the required credentials such as their driver's license
> data (address, state, zip), health card, citizenship, transcripts,
> professional licenses and form of payment to pay the application fees.
>
> It only makes sense that the Web Payments solution address a methodology
> for interoperating with identity-based credentials.
>
> Eric Korb
> CEO, Accreditrust.com
>

I think your last sentence sums up my position on this, although I added a
proviso.
Would you agree with the 3 statements below?

The *payments *standard should "address a methodology for interoperating
with identity-based credentials" where this is required to execute a
payment.

The *payments* standard shouldn't *define* an identity-based credentials
standard.

An *identity-based credentials* standard that is developed/incubated by
this group should not become a required dependency of the *payments*
standard if possible.
Rather, it should be one of the identity standards that is supported
(Normative examples used in the specification may predominantly use this
standard).

Adrian


On 27 June 2014 05:30, Manu Sporny <msporny@digitalbazaar.com> wrote:

> On 06/26/2014 04:40 PM, Adrian Hope-Bailie wrote:
> > I agree 100% that identity is a major issue and needs to be solved.
>
> Yay.
>
> > As I dig into the Identity Credentials stuff I can see how this may
> > be a great approach.
>
> We've yet to see if it will gain adoption, but at least it's there as a
> counter-point to the other identity solutions out there.
>
> > My issue is this:
> >
> > We have agreed that we want to put together a standard that uses
> > push payments ( I think this is what we agreed?). I define push
> > payments to mean: 1. The payer initiates the payment via their
> > provider of choice (using a mobile, internet, whatever channel that
> > they trust between them and the provider). 2. The provider processes
> > a payment to the payee. 3. The payee gets some form of notification
> > that they have been paid and they trust this.
>
> So far, so good.
>
> > Other steps like invoicing, exchanging identity credentials,
> > selecting/negotiating terms are not essential.
>
> I agree that they're not essential for moving money from the payer to
> the payee. We're shooting for a good UX as well, though. A commercial
> purchase w/o the choice of receipt or where the result is a receipt that
> provides the same experience as the receipts we are given today is not
> very compelling (and will likely fail).
>
> I don't know if we really need to discuss this stuff further, though. We
> (Digital Bazaar) will implement the optional parts that you identify
> because we don't believe that our products will be compelling without them.
>
> > I will bet that 99.99999% of the people involved in the projects,
> > start-ups or initiatives you have linked to are trying to solve one
> > of the following problems: 1. KYC - A payment provider getting proof
> > of identity credentials for a new customer when they sign them up 2.
> > Protecting identity (and payment) data of a payer when it is passed
> > via the payee and the rest of the payments ecosystem onto their
> > provider (card issuer). i.e. Most payments today. 3. Generic identity
> > exchange and protection issues which are important for things like
> > eGovernment, privacy etc
>
> There are two more which are 4) single sign-on for the Web, and 5)
> solving the NASCAR payments problem. A simple specification that can be
> implemented in a matter of days solves all five of these issues in one go.
>
> That said, no need for us to try and convince each other of the need (or
> lack thereof) for this part of the technology stack. As long as there is
> an extension point that provides it, we will implement it because we see
> it as a competitive advantage.
>
> -- manu
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: The Marathonic Dawn of Web Payments
> http://manu.sporny.org/2014/dawn-of-web-payments/
>
>