W3C home > Mailing lists > Public > public-webpayments-ig@w3.org > March 2016

Re: Drafty VCTF Use Cases

From: Ian Jacobs <ij@w3.org>
Date: Wed, 9 Mar 2016 14:48:18 -0600
Cc: "public-webpayments-ig@w3.org" <public-webpayments-ig@w3.org>
Message-Id: <EA38F3E5-187C-4517-886A-0E30399B1625@w3.org>
To: Shane McCarron <shane@halindrome.com>
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




Received on Wednesday, 9 March 2016 20:48:21 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 9 March 2016 20:48:22 UTC