Re: Use Case Refactoring v1.0

I think we need to do user-stories.  Something we can structure to promote engagement via webwewant.org and related initiatives.

Any chance you can put that, or something along those lines, onto the agenda? 

I'm happy to process responses.

#  Perhaps we need a pre-defined subject heading 

"call for user-stories: webpayments" and intro text..

#example / draft text / body

We're working on a standard for web-payments.  The standard incorporates the benefits of linked data.  As part of this initiative, we're looking for use-stories that help explain some complex issues with regard to commerce over internet protocol, and related instruments.

These user-stories can be real, or made-up.  We ask for them to be written in English.

We know that different regions in the world have different rules around commerce and trade.  

By contributing user-stories, you'll be helping us ensure, we've got all the potential problem areas covered, that we'll have the functional solutions and/or the means to define them.

To Join the group see (w3 communities link here).

For more information see the following resources.
URL
URL
URL


Thoughts??



Sent from my iPad

> On 30 Apr 2014, at 8:51 pm, Andrew Mackie <andrew@supplydemand.info> wrote:
> 
> Hi Manu (and Tim),
> 
> Just a quick email to let you know (prior to your conference call today) that I'm back on deck (I was away until yesterday) and will start working on the use cases again shortly. Tim Holborn has expressed interest in collaborating with the use case refactoring and we had a call yesterday to get to know each other (but didn't have time to start talking about use cases).
> 
> Thanks for your responses to my questions - much appreciated. I've read through them briefly and will start to go through them properly, with replies / further questions going to the list.
> 
> Regards,
> Andrew
> 
> 
>> On 27/04/2014 05:52, Manu Sporny wrote:
>>> 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
>> 
> 
> -- 
> Andrew Mackie
> website: www.supplydemand.info
> twitter: @SupDemand
> email: andrew@supplydemand.info
> mobile: +61 (0)432 488 762