Re: Drafty VCTF Use Cases

Thanks for your comments, Ian.  I will integrate in the comments branch
shortly.

On Wed, Mar 9, 2016 at 2:48 PM, Ian Jacobs <ij@w3.org> wrote:

> On Mar 7, 2016, at 5:29 PM, Shane McCarron <shane@halindrome.com> wrote:
> >
> > (resending this - my new address is not yet on this mailing list. grr.)
> > ---------- Forwarded message ----------
> > From: Shane McCarron <shane@spec-ops.io>
> > Date: Mon, Mar 7, 2016 at 5:15 PM
> > Subject: Drafty VCTF Use Cases
> > To: Credentials Community Group <public-credentials@w3.org>, "
> public-webpayments-ig@w3.org" <public-webpayments-ig@w3.org>
> >
> >
> > I assume there is a VCTF meeting tomorrow.  My action was to update the
> use cases document into the new IG VCTF space in preparation for a tight
> coupling between it and the draft verifiable claims charter. The charter
> has not yet made it into this space - I know that Manu has been moving
> house AND been ill, so I imagine he is just a tad behind.  But the draft
> use-cases are up at http://w3c.github.io/webpayments-ig/VCTF/use-cases/
> >
> > Please have a look in anticipation of discussing these tomorrow and over
> the coming week.
>
> Hi Shane,
>
> Here are some comments.
>
> Ian
>
>  * "From educational records to payment account access, the next
> generation of web applications will authorize users to perform actions
> based on rich sets of credentials issued by trusted parties.”
>
>    I suggest instead:
>
>    "From educational records to payment account access, the next
> generation of web applications will authorize users to perform actions
> based on rich sets of credentials.”
>
>    It is not clear that the parties will be trusted (and certainly don’t
> have to be trusted a priori; trust is earned).
>
>  * Definition of holder: "An entity that is in control of a particular
> credential.” What is the definition of “control”?
>
>  * "Asako just passed the final test to receive a drivers license….” I
> don’t think this use case illustrates the value of the proposal. Drivers
> licenses work fine today. What is possible in the future
>     is lower distribution costs, easier updates (e.g., I move to a new
> address), easier replacement of “lost” licenses, easier to revoke, harder
> (perhaps) to fake, etc.
>     It seems that those should be the points here (in essence, the value
> of going digital).
>
>  * All the use cases are deemed “Essential” and thus I suggest removing
> that label for all of them and saying that there are other use cases
> elsewhere.
>
>  * "An entity, such as an end user (holder), wishes to make a claim and
> would like it to be endorsed by a different entity (issuer) which may then
> be trusted by a potential consumer (credential consumer).”  It seems this
> should say:
>
>     "An entity, would like an issuer to issue a claim.”
>
>    In other words, in this system, what matters is issued claims. So I
> don’t have any claims until they have been issued (by me or, more
> interestingly, by a third party.)
>
>  * "It MUST be possible for a credential consumer to verify credentials as
> genuine.” That seems unlikely to happen. Maybe instead you could say:
>     "It MUST be possible for a credential consumer to verify some
> cryptographic conditions of a credential.”
>
>  * "A consumer may require that a holder verify aspects of their
> suitability for a transaction. In this case, the holder must be able to
> select which, if any, Verifiable Claim stored with their Credential Curator
> is used to satisfy the consumer.”
>
>   It would seem preferable to express this use case without an assumption
> that there is a credential curator. Or maybe the answer is state in the
> definition of holder that the holder
>   has access to stored credentials (which may be managed by a curator) and
> then you don’t have to talk about curation any more; you just talk about
> holders.
>
>  * "Anna has opened an account at her bank in Finland.” The scenario
> doesn’t obviously relate to the use case, which is about being able to
> select from among several.
>
>  * "It MUST be possible for a consumer to verify that the credential is an
> authentic statement of an issuer's claims about the subject.”
>
>    How is this different from 4.1.2:
>
>    "It MUST be possible for a credential consumer to verify credentials as
> genuine.”
>
>  * "June goes to her local beer and wine store to buy a bottle of wine.
> She submits her identity credential that lets the liquor store owner know
> that she is over 21 without having to reveal her actual date of birth, her
> address, or her state ID number.”
>
>   This seems very hard to guarantee generically. How do you plan to enable
> any claim to be transformed (and still verifiable) into a claim that aligns
> with what someone wants to know?
>
> --
> Ian Jacobs <ij@w3.org>      http://www.w3.org/People/Jacobs
> Tel:                       +1 718 260 9447
>
>
>
>


-- 
-Shane