Identity vs. Payments. Was: "Web Identity" -> "Web Credentials"

On 2014-03-06 06:27, Manu Sporny wrote:
> On 03/05/2014 05:38 AM, Anders Rundgren wrote:
>> My concern is really on a more fundamental level: Who is the actual
>> consumer of these identities?
> 
> Generally speaking, any entity (person or organization) that needs to
> verify a piece of information about you. These entities include websites
> you're logging into (verify email address), merchants and stores
> (preferred payment processor), banks (KYC information such as government
> issued ID), employers (certifications, licenses), and governments
> (address information, birth certificates).

IMHO, mixing payment protocols with identity is slippery path which I wouldn't
personally try.  I don't think that merchants [absolutely] need _verified_
user data, they essentially only need to trust your payment resource.

KYC w.r.t. the payment provider/bank is a _one-time_process_ with many
local variations making it less suitable as a target for standardization.

So how would you then provide customer data in the case where it is
actually required?  Although ECML (http://www.ietf.org/rfc/rfc3106) failed,
a modernized version could be useful since it gives consumers full control
of what they share with merchants at the potential cost of one extra
click/touch operation.

Regarding _selective_disclosure_of_verified_user_data_, it seems that
Microsoft's to date unsuccessful U-Prove scheme could be a part of the plot.
If this is the case (unfortunately a bit outside of my core competence...),
you could eliminate the boring e-mail "round-trip" that each and every site
force upon users, regardless if we are talking payments or not.

In fact, it is even possible that "ECML+" and U-Prove could be combined!

This obviously increases the scope of the project but OTOH splitting the
work into a number of reusable and loosely connected "nuts and bolts" also
makes it more manageable.  SKS/KeyGen2 is an example of such a component.

Anyway, I don't want to disturb the WebPayment process, I only wanted to
point to what I consider problems as well as to potential opportunities.

Cheers
Anders

> 
>> In the conventional payment world (which I know more about than 
>> WebPayments), you identify yourself (in some way...) to a payment 
>> provider _once_.  After that you get access to a payment resource 
>> which does not necessarily expose your identity.
> 
> These identities are used to expose the payment resource to the
> merchant. So, for example, when you login to a website, that login
> process may certify your email address and mobile number (so the
> merchant can get in touch with you if there is an issue), your payment
> provider (so a payment can be initiated), and your shipping address (so
> the merchant can ship the good to you).
> 
>> It is IMHO rather the opposite, the _less_ identity you have to 
>> provide during a payment operation the better.
> 
> Yes, for certain goods. At a minimum, most people provide their email
> address, shipping address, and payment provider for physical good
> purchases over the Web. The goal is to only expose as much as is
> absolutely necessary, and there is certainly a plan to support low-value
> pseudo-anonymous digital transactions.
> 
> -- manu
>

Received on Thursday, 6 March 2014 07:39:51 UTC