Re: VOTE: Revised Identity Web Payments Workshop Use Cases

On 07/16/2014 12:15 AM, Steven Rowat wrote:
> On 7/15/14 6:29 PM, Manu Sporny wrote:
>> 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).

For a non-expert, you seem to have a very firm grasp on the dangers of
attempting to solve identity at the same time as payments. :)

> 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?

It's sort of the same problem. We're attempting to address a narrowly
scoped subset of the "identity problem". Basically, we have to have a
way of storing and transmitting credentials (verified shipping
addresses, proof of age, digital passport, etc.) in a
privacy-protecting, anti-pervasive monitoring way.

This doesn't mean that we have to prove that
https://example.org/people/steven is you, we just have to be able to get
some set of credentials from that URL that allows us to meet our
regulatory compliance requirements. For example, digitally verifiable
proof that you're a citizen of your country, are of legal age, and are
not a terrorist if you're planning to send a large chunk of money
overseas. :)

> 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.

Yes, agreed. There is a bit in the meeting minutes from last week and
yesterday that contain more detailed discussion about this. We'll try to
get the minutes published tomorrow.

> 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.

My opinion at the moment is that we can't do justice to the Web Payments
problem w/o addressing at least part of the identity problem. For
example, we /can/ make it easy to buy digital goods from the Internet
w/o solving the identity problem. We can't make it easy for businesses
to transact w/ one another w/o solving the identity/KYC/AML problem.

The risk we run by ignoring the identity problem is creating a toy
solution for low-value transactions, thus forcing a different solution
for high-value transactions. This will make the web payments solution
more complicated that necessary and could lead to its failure.

We want to make rapid progress. We also don't want to paint ourselves
into a corner.

We've tried to figure out a way to not have to address both as doing so
would be difficult... but we don't see a technical way around the
problem yet.

The current plan is to try and break the identity work off into another
group focused on Web-based, verifiable, high-stakes credentials. We have
some big players that would support that work elsewhere so that we can
focus on the Web Payments stuff here. So, this group wouldn't have to
take on the entire burden of attempting to solve the credentials problem.

>> 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?

The purpose of this was to provide the customer and merchant the ability
to request more information about the counter-party in the transaction.
The information wouldn't be released w/o the consent of the entity in
control of the information.

For example, a customer gets a product and it's defective. They could
use the digital receipt to get the merchant URL, discover the merchant's
contact information, and automatically dial the customer service line to
ask for a replacement.

So, the NSA couldn't get your information unless they have direct access
to your identity provider (which, for the truly paranoid, would be a
device wrapped around your wrist that only you control). Google can't
get access to the data because they have to ask you to release the
information (and presumably you'd say no if you didn't want them to have
it). It's constitutional in the US because the information provider
(e.g. customer) is always asked to release their information. The people
that need to discover attributes are the ones that need to interact w/
the transaction participants after the purchase has occurred. You can't
ask the participants unless you have a unique identifier for the
participants.

Really, this use case is about trying to say "all non-anonymous
transactions should mark each participant with a URL identifier that
allows the participants to request information from each other after the
transaction has occurred."

>> 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?

OpenID Connect is a Google/Microsoft/Yahoo joint venture, so no, it
would be outside of W3C. The Identity Credentials stuff we're working on
would go through W3C. Depends on the technology, but whatever it is, it
would end up being a necessary component 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?

The spec work may or may not be inside the W3C process. The technology
would be a requirement for the Web Payments work.

> 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?

The Identity Credentials demo has a mechanism that would allow multiple
identity provider mechanisms. So you could use OpenID Connect, Identity
Credentials, or Ripple Identity for example. The mechanism would
probably not be standardized but would operate through a browser
polyfill (a piece of software that lives in a centralized place on the
Web at first, but would eventually be implemented natively in browsers
if it takes off).

> 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?

Someone is going to be mad. We don't want to piss off the OpenID Connect
folks, so we have to figure out how to integrate with them. We also want
to ensure that things like the Ripple Identity stuff could work as a
identity credential storage mechanism.

> 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?

Yes, this is also a danger.

Fundamentally, we have to figure out how to do the following:

1. Assign an identifier to an entity that is part of a transaction.
   We're suggesting that we use an HTTP URL for now.
2. Establish a mechanism that allows credential information to be
   written to and read from that identifier in a privacy-protecting
   way.

We might be able to do both in a way that allows us to migrate to better
mechanisms in the future w/o affecting the rest of the Web Payments
stack in a catastrophically negative way.

>> 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.

Hmm, I don't remember and I can't find out when we decided on this
wording. There are two choices here:

1. Enable a digital cash equivalent (which I remember us shying away from).
2. Create anonymity at the payment processor and merchant level, but
still enable a government or law enforcement to find out w/ the
appropriate authorization.

I'll try to find out which one we meant after publishing the minutes
from the last two weeks of calls.

>> 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.

Does this make more sense?

Use Case: Jack wants to pay Amazon Incorporated using their short
identifier "Amazon". Prior to sending the payment, some information
(like a human readable, digitally signed certificate by Dun and
Bradstreet) associated with the short identifier "Amazon" indicates to
Jack that the short identifier is a verified short identifier for the
merchant (Amazon).

>> 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?

The original purpose for the use case was to ensure that (given a
two-factor authentication requirement using a public/private key), if
you lose your key, another key (like one associated with your spouse,
child, family member, or friend) could authorize the use of a new key
for your account. It's like giving a spare key to your house to a
neighbor that you trust (in the event that you're locked out).

> What are the implications...

There are many. :)

> such as, will all their credentials merely switch over seamlessly at
> all the providers?

Yes, ideally.

> Will all KYC and other legal entities be in the loop, or does this
> cause anonymity/laundering problems?

No, KYC and other legal entities still don't have access to your
information unless you explicitly grant access to them. I don't think it
causes any anonymity/laundering problems, but to be honest, we haven't
put a great deal of thought into those sorts of side-effects.

> By 'lose the ability', could you also be including a government
> taking away someone's identity or controlling it

Well, in the super-paranoid, public/private key crypto example, the
government can't take away your identity because you own the key and
your identity credentials live on your Internet-connect wrist strap. The
only way they can take your identity credentials away from you is via
force (physically removing the devices from your possession... and then
they'd have to "convince" you to give them password).

> -- 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...

Yes, that's possible, but not as a side-effect of this particular use case.

> Is there room for this type of Great Game?

Yes, because it's already reality. Anyone that has been granted asylum
or has been identified as a double-agent is in this position (luckily, a
very tiny minority of people).

-- 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/

Received on Thursday, 17 July 2014 05:03:03 UTC