Re: VOTE: Revised Identity Web Payments Workshop Use Cases

On 7/15/14 6:29 PM, Manu Sporny wrote:
> Please +1/+0/-1 each identity use case below in order to show whether or
> not you agree ..


> Use Case: Store basic identity credentials and payment provider
> information on the Web in a way that is easy to share with various
> merchants given authorization by the owner of the identity, and that is
> easy to synchronize between devices.
> Notes: This includes the ability for the identity owner to manage the
> identity information. It does not include the ability for the identity
> owner to automatically sell their identity information.

+1/+0
Not sure...it seems (as a non-expert) that identity is as big a 
problem as web payments (that is, as the payments mechanism that would 
be required if the identity problem were already solved). But perhaps 
not, if 'storing' identity credentials is a different and simpler 
thing from the verifiable-identity problem (i.e., than the issuing of 
credentials and being able to use them in a secure way), -- or is it 
the same problem?

If so, I think we need to have more discussion about identity's 
implications before deciding whether to attempt to do it together with 
web payments.

IMHO, it may turn out that without identity being solved, web payments 
will not be solved (or substantially improved in the way we are 
envisioning), -- in which case it may turn out that identity needs to 
be addressed first, rather than the other way around. But even then it 
might be best not to try them both at once.


> Use Case: A customer visits a website and authorizes the transmission of
> one or more pieces of information (such as proof-of-age, shipping
> address, etc.) previously stored with an identity provider to the
> website to enable access or fulfillment of a transaction.

+1/+0
As above.


> Use Case: Using metadata that is the result of a transaction, discover
> attributes associated with the identity of participants in the transaction.

-1
As this stands... -- wouldn't someone in the NSA be doing exactly 
this? Or Google, to get data to drive advertising revenue? Isn't there 
a good case that this is unconstitutional in the US? :-)  I don't 
think this is what you mean...but what do you mean? Who needs to 
discover attributes associated with the identity of the participants? 
Why not just ask the participants?


> Use Case: Digitally verifiable credentials such that a merchant and
> payment processor in a transaction can prove that they have done due
> diligence in verifying the customer's identity (KYC).

+1


> Use Case: A customer executes a transaction without revealing secrets
> that are not vital to the transaction (i.e. identity, passwords, PINs or
> other information that the merchant does not need to know).

+1


> Use Case: Use an existing, widely deployed identity provider mechanism
> (i.e. OpenID Connect) to integrate with the digital credentials sharing
> and payments initiation process.

+0
Not sure what is implied here -- would the 'existing, widely deployed' 
mechanism be part of the specification and go through the same W3C 
process, and end up being a supported (necessary? sufficient?) part of 
the whole mechanism? Or is it implied that the i.d. provider mechanism 
would remain outside the W3C process, which would nonetheless be 
designed as a socket for it? Or would the payment mechanism have a 
socket that could fit any number of identity provider mechanisms, 
without prejudice, but this one is being specified so that there will 
at least be one example that works for sure? If so, are there 
downsides to this? For instance, are there other provider or potential 
provider mechanisms whose developers will be annoyed by being passed 
over? Or, are there yet-to-be imagined mechanisms that might be better 
than the chosen existing one, potential mechanisms which will now fail 
to be developed because one has been already blessed by (association 
with) the W3C?


> Use Case: Transact with a merchant without revealing any identifying
> information. Identifying information is available to the payment processor.

+1

> Use Case: Enable anonymous transactions such that the identity of the
> customer is not discoverable by merchants or payment processors.

+0
Do you mean 'but can be discoverable by governments or law enforcement 
when they have appropriate authorization'?  If so, +1, but I think it 
would be best to include that explicitly.


> Use Case: Jack wants to send Jill some money and asks Jill for a short,
> memorable payment identifier. Jill sends the payment identifier to Jack
> via an SMS message. Jack makes a payment using the short payment
> identifier; the payment processor translates the short payment
> identifier into a destination financial account for Jill.

+1


> Use Case: A person pays a merchant using a short identifier. Prior to
> sending the payment, some information associated with the short
> identifier indicates to them that the short identifier is a verified
> short identifier for the merchant.

+0
Don't understand this one; ambiguity for me in at least two places. At 
first I believed the 'short identifier' was a label for the 'person', 
ie, identified the person to the merchant. Then I couldn't figure out 
the antecedent of 'them' in the second sentence (is it the person, or 
the merchant, or both of them?) Then in the last part of that sentence 
it seemed likely, but not certain, that 'short identifier for the 
merchant' indicates that it's the merchant, not the person, who is 
represented by the short label. It could also mean it's representing 
the 'person', but provided 'for' the merchant. If I had to bet I guess 
I'd go with the former, rather than the latter. But I'm really not 
sure. :-)

Maybe you could use names, like the Jack and Jill example? That seemed 
easier to follow.


> Design Criteria: A person sets a second identity as a backup for
> accessing their first identity, should they lose the ability to use the
> first identity.

+0
In theory it seems like a good idea, but maybe is too general? What 
are the implications...such as, will all their credentials merely 
switch over seamlessly at all the providers? Will all KYC and other 
legal entities be in the loop, or does this cause anonymity/laundering 
problems? By 'lose the ability', could you also be including a 
government taking away someone's identity or controlling it -- let's 
say someone in China is blacklisted by their government, but someone 
in, Oh, just for a random example, the United States government, 
disagrees and says, fine, we'll honor your second identity and not 
your first, and then everybody will be happy... Is there room for this 
type of Great Game?

If so, what fun it will be. ;-)


Steven Rowat

Received on Wednesday, 16 July 2014 04:16:02 UTC