- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Thu, 15 May 2014 14:42:26 -0400
- To: public-webpayments@w3.org
On 05/04/2014 11:01 PM, Tim Holborn 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. >> >> DESCRIPTION (aka User Story) --------------------------- >> >> [[2-3 paragraphs outlining the use case]] >> > > TELEHEALTH Hey Tim, what you wrote is great in that it outlines a class of care that requires both exchanging private information and making payment. The downside is that it's far too broad and pulls in too many variables for a simple description for the use case above. Remember, these use cases need to be fairly self-contained and easy to understand. That means that we can't require people to understand entire market verticals in order to understand the use case. The description should also be focused specifically on just the use case and shouldn't try and expand beyond the use case. Hopefully, the example below demonstrates what we're looking for wrt. simple descriptions of use cases: ---------------------------------------------------------------------------- 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. DESCRIPTION (aka User Story) --------------------------- Milo wants to buy a nice bottle of wine for an upcoming dinner party from his favorite winery's online store. To complete the purchase, the winery needs Milo's payment provider, shipping address, and for him to prove that he's of legal age to make the purchase. While he setup his online identity using his tablet, he uses his mobile phone to access the winery's website. The winery's website requests a set of 3rd party verified credentials asserting that he's of legal drinking age in his country, his payment provider information, and his shipping address. His identity provider notes that the website is requesting proof of his age, payment provider, and address. After seeing the information that will be transmitted to the website, Milo approves the transmission and the website verifies that the credentials are valid before allowing the purchase to proceed. REQUIREMENTS (optional) ----------------------- * A way of denoting a particular entity (by using a URL, for instance). * A mechanism to express arbitrary credentials associated with an entity on the Web. * A way for a 3rd party to assert verifiable information about a particular entity (such attributes coupled w/ a digital signature). * A mechanism for a website to request particular attributes of an entity. * A way of transmitting credentials from an identity provider to an arbitrary website. * A way of verifying that the credentials transmitted are valid in a way that doesn't involve the issuer of the credentials nor the assignee of the credential (for example, via a digital signature verification). -- 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, 15 May 2014 18:42:49 UTC