Re: Request for user story - Store basic identity credentials

On 16 May 2014 04:42, Manu Sporny <msporny@digitalbazaar.com> wrote:

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

cheers...

the areas of exchanging private info - isn't within scope of the payments
charter.  However, the bridging factor would be the identity modelling,
which i assume could best be classified as a electronic contract document
model.  That is, that two verified identities have made an array of
agreements which have an economic or commercial consequence now or in the
future.

given the complexity, my thought was that the user-stories can help to
describe what are very complex situations, handled currently with
cumbersome (and expensive) processes. So, I figured it gave a complex
example where a multitude of functional requirements could be examined
surrounding a type of use-case. Another example could be a live-sporting
event, with user-participation (interactive broadcasting, perhaps with
betting..).  Perhaps the Broadcast is provided by a FTA (Free to Air) and
the application provided by 1funnel4gamblingmoney.tld.

More on the others later.

In boiling the provided user-story down to use-case; i figure it goes
something like this...

The use-case appear to be an example of an e-contract bonding a digital
object to actors; acting as an authorisation mechanism, for an array of
web-payment transactions.

1. A 'digital object' (the Video Session for example) has e-contract
Authorisation
2. An e-contract is facilitated to access that digital object
3. The e-contract may require approve/deny functionality to a 3rd party
(private) data-system
4. the e-contract may include a requirement for payment from the provider
5. the e-contract may provide payment approval to a 3rd party provider.
6. the e-contract will have common-properties defined prior to 'runtime'.
(ie: identity information of email addresses of invited participants,
demographic data, level of identity verification required, payment
commitments, privacy settings, etc.)

Perhaps herein; the concept outlined by the use-story / use-case, is of an
"electronic contract document model"; which then ties into your commerce
model. Data from this e-contract workflow (?)  enable payment to parties,
where existing vocab seems rather stable in how the payments specifically,
are delivered / facilitated.



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