Re: Use Case Refactoring v1.0

On 04/24/2014 10:51 AM, Andrew Mackie wrote:
> Following a conversation with Manu and Brent last week, I've started 
> the task of categorizing the use cases from a conceptual standpoint 
> in order to ensure that a) we include every use case that we need and
> b) the final set of use cases is well structured to aid 
> understanding.

Great first cut at refactoring, Andrew!

> As you can see, I've added a number of comments and questions and 
> I've identified a number of gaps that we need to fill in. I will 
> continue to play with the structure - in the meantime I appreciate 
> your comments, answers, identification of gaps and so on.

Responses to your questions (not gaps) below:

> Identity / Trust: Is there any approval process / commons which will
>  allow users to identify which apps are safe?

There definitely shouldn't be an approval process (centralization and
provides a choke point for keeping competitors out). We could have
nothing (which is the state of affairs today, nobody tells you which
bank you should bank with). We could also have a blacklist (known
phishing / scam sites - Google Chrome has a great implementation of this
and it wouldn't require us to do anything extra).

> Assessing payers / payees: These two tasks (1. verifying identity
> and 2. Assessing trustworthiness) are distinct and important pieces
> of work which IMO should be separated into separate use cases. The 
> latter (assessing trustworthiness) is a massive piece of work that 
> IMO should be outside the scope of this project.

+1, agree completely.

> Know Your Customer (KYC): [Question] What are our design criteria for
> this element?

The minimum would be to enable banks to share KYC clearing information.
This would include, at a minimum, name, birthday, government ID,
nationality.

> Is there anything else that needs to be done to help users meet
> their KYC obligations?

Replace "users" with "payment processors", they're the ones that are on
the hook to meet KYC obligations.

> Identification Methods: Place identity in a decentralized network - 
> What other goals do we have here?

That's not really a goal. The goal is "Provide an entity with a portable
digital identity". One way to do that would be to store it in a
decentralized database (good idea, but requires more work). Another
would be to write a specification elaborating on how you would export
your identity from one identity provider to another identity provider
(bad idea, but easier to make incremental progress on).

> App Stores - selling apps in mobile scenarios: What is unique about 
> this use case, that it's worthy of a specific mention here? Is it a 
> different form of identity (tied to the phone / SIM card / Accounts 
> on the phone)?

There's nothing really unique about identity and app stores, the same
identity mechanism should be used for all the payment use cases. It is
important to be able to tie identity to a mobile ID number (phone
number, UICC number, SIM number, etc)

> [Rewrite] Knowing that data minimization principles are followed by 
> systems in a payment chain

I don't really understand what this use case was intended to achieve.
We'll have to ask the use case scribe that wrote it down.

> Privacy / Anonymity: Is it enough to make this visible to users, or 
> should it be a minimum standard for participants in the payment
> chain (apps and payment processors)? If so, how do enforce that
> standard (my suggestion is to allow users to express demand for apps
> and processors which meet these minimum standards)?

This wanders into the policy space, which we will have very little
control over. We can't really prescribe anything, and limiting the
technical spec will just ensure that large implementers will ignore the
advice.

> Privacy / Anonymity Use Cases -  Leveraging variable degrees of 
> identity/anonymity per requirements of the payment transaction. What 
> do we mean by this?

This means that you don't need to provide your government ID number if
all you are doing is buying a litre of milk or a single tank of
gasoline. However, if you are buying a home, you will most likely need
to provide your government ID to the financial crimes regulatory body in
your country during the transaction because the financial exchange will
trip an anti-money laundering regulatory event for your financial
institution (your bank already does this).

If you are buying a handgun, you will need to provide a different set of
information (for a background check, for example). Even more information
(like a government issued license and other digital paperwork) will be
needed if you're buying enriched uranium, and so on.

> Identity solution must not rely on passwords for primary 
> functionality. What should the identity solution rely on (if not 
> passwords)?

This is a bit misleading, you will still have a password, most likely...
but it will be hooked up to a two-factor authentication method. Ideally
it would be based on public/private key cryptography, but even the
keychain on the device you're using would most likely be protected by a
PIN or password.

> Identity solution must not rely on passwords for primary 
> functionality. What constitutes 'primary functionality'?

"Primary functionality" would be, proving that you are who you say you
are. We may not be able to get away with not using passwords until all
of us are carrying around cheap public/private key hardware (most
likely, our mobile phones).

> Payee-Initiated payments- Use Cases - Payee initiates a request for 
> payment How do we prevent / limit unsolicited requests for payment
> (a new type of highly profitable spam)?

Is this a problem today? There's nothing preventing someone from
requesting payment whenever you hit any website, but most don't because
they know it'll almost ensure the visitor won't come back.

There are concerns over triggering any kind of browser payment API. That
will most likely use the same protections that are used today: Ensure
that any trigger of the API would have to be initiated by the person
browsing via a mouse click or tap.

> Methods of Receiving Receipt - Use Case - Customer can receive 
> digital receipts (receipt POSTed to user's digital receipt storage) 
> Implies storage capacity for receipts within the payment app
> (wallet) ... should this be a specification?

If we decide to make it a use case we support, it will be a separate
specification.

> Where / how do we intend to set minimum specifications for payment 
> apps (wallets)?

I don't know what you mean by where. "How" will be through the same
process we set minimum requirements for all specifications created
through the W3C. That process is collection of use cases, determining
which use cases to support by building consensus, design of technology
to meet the use cases, debate over the best mode of operation for the
technology, and finally building consensus around the solution. We then
iterate on the technology every few years until something better comes
along.

> Receipts - Possible Extensions - Payments / digital receipts should 
> be applicable to Encrypted Media Extension authorization to show 
> content. Does this really relate to contracts (discussed later) where
> the EME is the software-based embodiment of a license granted to the
> payer because of their payment?

Yes, it's more contracts related rather than receipts related. That
said, a receipt is a special form of contract/proof of purchase. I think
you've proven that you understand the nuances here, so I won't elaborate
unless you'd like me to.

> Receipts - Possible Extensions - Secure Element-based offline
> payment - By this do we really mean offering a receipt for a payment
> that isn't a web payment (whether that's via NFC or something else,
> e.g. cash)?

What we mean is that two people should be able to meet far away from
civilization and, using their mobile devices, agree to a transaction,
counter-sign a contract using digital signatures, and sync that
transaction w/ the global financial network when they come back online
(even if they come back online years later).

> Sale of assets - Use Cases - Managed access to personal 
> identity/attributes as economically valuable assets in a payment 
> system Notes: First iteration would probably not focus on the 
> "economically valuable" dimension of the personal identity attributes
> What do we have in mind here, the ability to sell the right for third
> parties to access your data (as proposed by Jaron Lanier in 'Who owns
> the future?')?

For the second iteration, yes, the Jaron Lanier view of this.

However, for the first iteration, this merely has to do with the ability
to prove that you are who you say you are by showing a website a digital
ID card of sorts. For example, "I am Andrew Mackie because I have this
token that was digitally signed by the Australian government proving
that I am who I say I am."

> Unsorted Use Cases [Rewrite] Knowing what info will be required to 
> supplement a transaction. [Question] What kind of info do we have in
>  mind here? What do we mean by 'supplement'?

When you buy a firearm, as a merchant, you may want to supplement the
receipt with a proof that you did a background check on the individual
and it came back as authorized. By supplement, we mean "add information
to the digital receipt in some way".

> Unsorted Use Cases [Rewrite] Protect privacy when making purchases 
> using geolocation technologies. [Question] Do we mean protect people
>  *from* others who are using geolocation technologies?

Yes, kinda. We mean "protect people that could reveal their geolocation
to a party that does not have their best interest in mind". It's a
slippery slope, very hard to classify "protect" and "best interest".

> Unsorted Use Cases [Rewrite] [Not in initial scope] Realtime 
> purchases involving prerequisite reception of funds from 
> international sources (e.g. family). [Question] Do we mean some kind 
> of just-in-time system where we tie together two otherwise separate 
> transactions?

I think we're going for something like the following:

"I'm in Mexico and I would like to buy this mobile phone so I can call
home, the funding source will be my mom in Canada."

> Once I've cleaned it up some more and incorporated this initial 
> feedback I'll find a way to open it up for a more immediate / open 
> form of collaboration (and any suggestions on the best format are 
> welcome!).

The Web Payments wiki has historically provided the best collaborative
output in this group (most number of people contributing to a single
document):

https://www.w3.org/community/webpayments/wiki/

-- 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 Saturday, 26 April 2014 19:53:19 UTC