Re: UseCases

Cheers.

NB.  I attempted to give use-cases on a few levels.

1. Technical
2. Technical Marketing

In an effort to engender participation and support (awareness) of the spec work; i figured, it’s useful to declare different use-cases for the technology that may not be technically required (use case) but be iteratively relevant for new-comers looking for solutions to problems (user-stories).

I have to follow-up more about the legals; but the theory i was trying to pursue around credentialing, was in an effort to pass the ‘legal instrument’[1] test.  In theory, a multitude of transaction types, denote this concept of being a ‘legal instrument’ although the technical reality of those processes simply do not pass the relevant tests required to establish that level of ‘acknowledgement’.

1. Identity; an agreement must be made by two particular individuals (as intended, no identity fraud)
2. Acceptance: they both understood what they were agreeing to, etc.
3. a ‘legal’ record & "tamper evident": some sort of proof of the agreement is available to both parties.  This “proof” has the relevant information required for legal arbitration surrounding the facts of whether or not that ‘act’ was carried out, inclusive of relevant particulars. 

Situations where these ‘tests’ are not for filled, arguably include;

- Email  (including e-commerce receipts) 
- Print (including e-commerce receipts) 
- Online Persona (online accounts)
- Access to Persona (access to online accounts)

(this is a non-exhaustive list)

Yes - people can add encryption to email - it’s MOST often not done. 

Within the field of credentials, additional capabilities are of course being considered.  These new use-case (fields) both take into account new applications of Web (i.e.: IoT) and new opportunities, where a credentialing spec exists. (as below)

I do acknowledge the cross-over between ‘credentialing’ and ‘payments’.  In particular; it is likely that the ability to have a verified receipt, is an optional receipt format - made available for some good purpose (i.e.: tax record or warrantee information) but is probably not needed for every receipt.


On 23 Sep 2014, at 1:27 am, Manu Sporny <msporny@digitalbazaar.com> wrote:

> On 09/14/2014 08:25 PM, Tim Holborn wrote:
>> A use-case concepts dump - types of credentials…
> 
> Hey Tim, I'm going to try and attempt to categorize your use cases into
> more generalized use cases to ease the flow of the conversation for the
> telecon tomorrow:
> 
> -------------------------------------------------------------------
> 
> Design Criteria: Support the following types of education, government,
> and healthcare credentials:
> 
> + I have a education degree in field X
> + I am a student, studying in field Y
> + I am a lecturer at university Z
> + I am a citizen
> + My date of birth is, etc.
> + I have a prescription / right to purchase this medication
> + I am an Emergency Health Professional
> + i have a valid First Aid Certificate
> + This is my Vehicle
> + This is my registered trademark
> + I have a yacht-club Membership
> + I am a Webizen
> + I work at Fast Food Chain xyz - Please authorise my discount
> + I work at Telecommunications Company XYZ: Let me in the door to this
> secure facility
> + I am a lawyer or Accountant
> + I am a Lawyer or Accountant representing this client
> 
> I suggest that we move these over to the Web Payments use cases:
> 
> + I purchased this TV within the last 12 months (i still have a warrantee)
> + I paid this bill on this day
> + My insurance for my yatch is paid
> 
> -------------------------------------------------------------------
> 
> Use Case: Enable access to patient storage for particular individuals.
> 
> + I authorise this doctor to write to my patient record
> + I reauthorise this doctor to write to my patient record
> + Emergency Health Providers can Access my Patient Records
> 
Spell-check apparently ‘fixed’ “De-authorise” above.
> -------------------------------------------------------------------
> 
> Use Case: A sender transmits some data to a receiver. The receiver
> transmits a digitally signed certificate of delivery to the sender.
> 
> + I have sent you legal notification digitally
> + I have authored this document which i seek to be delivered as
> registered mail to the named recipient
> + I seek a date-stamp (and checksum) on this document send to the
> specified recipient.
> (and i seek to declare terms to that transmission)
> 
> -------------------------------------------------------------------
> 
> Use Case: Credentials issuer seeks to share private information (web
> resources) with credentials holder.
> 
> Why is this use case not covered by SSL? Do you mean that the
> Credentials issuer needs to write information to the credential holder's
> online storage?
> 

Yes. 

related theory being; that pursuant to the ‘data rights’ concept (Something which i need to improve documentation…).  

INSTANCE 1:
I guess, this is similar to creating a symmetrical FOAF notation.  If the resource is HTML Based (using a FOAF / WAC example to explain) It’s simply an Add to the ACL’s.

NB: Current FOAF notation is plaintext (no checksum, etc.). 
  
INSTANCE 2:
If it’s a PDF, then same - but may then issue to keystore embedded into PDF document. 

 
> -------------------------------------------------------------------
> 
> Use Case: Individual is fined for traffic infringement and seeks access
> to Video (and/or audio) evidence recorded by law-enforcement.  A means
> is sought to do this privately (as to avoid the material being published
> on youtube).
> 
> -------------------------------------------------------------------
> 
> Use Case: A confidential document is being distributed for the purpose
> of disclosure and mutual agreement.
> 
> Why can't the distribution happen over SSL? Do you want the document to
> be transmitted over SSL and for the contents to be encrypted to the
> receiver? Then have the contents digitally signed and re-encrypted to
> the sender?
> 
My thoughts are that distribution vs. acknowledgement that it was not distributed due to a routine of a BOT.  

Disclosure process = restricted use (link to ID)
mutual agreement = tests relating to the execution of the document, by Identified party; using a “legal instrument”[1] (in-turn creating a legal instrument).
[1] http://en.wikipedia.org/wiki/Legal_instrument
> -------------------------------------------------------------------
> 
> Use Case: I have a hybrid TV service (Broadcast + Broadband) here is my
> identity details, i would like to control who and how this information
> is used for targeted advertising & other purposes.
> 
> Might want to remove the hybrid TV service bit, don't know why that's
> relevant? Maybe because of the advertising angle? You don't want to be
> advertised to using your identity information, but you need to use it to
> unlock the "over the age of 13" channels?
> 
Yes. Advertising / profiling angle.  (programming could also be personalised overtime, given technology..)

So, and old projects has come-up around an international spec called HbbTV [2].  In this new environment, personalised advertising is a remarkable opportunity to change the landscape around advertising funding for media.  Problem is of course, that people don’t necessarily want to be participating in further profiling whilst sitting after work.  Equally, TV is a household device - and if it’s profiled to one particular person (or indeed a persons particular persona) might not be what the family want to watch, or what the boy wants to present to grandma, or the girl to her new love interest, etc.

[2] https://www.hbbtv.org/pages/about_hbbtv/specification.php
> -------------------------------------------------------------------
> 
> Use Case: This intelligent light globe is connected at my home.  I would
> like access to the light globe to turn it on/off remotely.
> 
> Seems like a secondary case for authorized access to IoT device? Don't
> know if we need this one, as others should cover it.
> 
Not sure either.  Theory is; it would be good to ensure a hacker (perhaps the ex.) to mess with your settings before / after work…

> -------------------------------------------------------------------
> 
> -- manu
> 
> -- 
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: High-Stakes Credentials and Web Login
> http://manu.sporny.org/2014/identity-credentials/