- From: Shane McCarron <shane@halindrome.com>
- Date: Sun, 13 Mar 2016 23:26:41 -0500
- To: Ian Jacobs <ij@w3.org>
- Cc: "public-webpayments-ig@w3.org" <public-webpayments-ig@w3.org>
- Message-ID: <CAJdbnOCKV8H+PNBR9tm-NnWB4xBcmffzOOwH65czxmrLZZ6oTA@mail.gmail.com>
My comments / responses in line: 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). > Good one - thanks! > > * Definition of holder: "An entity that is in control of a particular > credential.” What is the definition of “control”? > I don't think having that defined is critical for this document. Would you prefer a word like "possession"? We didn't like that because it implied that the holder actually is "holding" whereas they might just be the entity that has access to the claim. > > * "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). > I understand your point. I may substitute in a different scenario here. In general these scenarios are targeted at expressing benefit for the individual (holder / subject), as opposed to the issuing organization. Arguably that is something that should be addressed as well. > > * 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. > Sure - that makes sense. > > * "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.) > I attempted to massage it while still retaining the motivation that the claim needs to be issued in such a way that it is verifiable and can be trusted. > > * "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.” > I disagree. Of course it can happen. To a very high level of confidence. > > * "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. > Credential Curator is a defined term too. It just means a place where credentials live. > > * "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. > Yeah - I tightened it up. > > * "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.” > I am not sure it is. The second version provides more detail. I > > * "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? > I don't think that is something that needs to be addressed in a use case document. We are stating requirements here. Implementation is something for future work, surely. However, to answer your question, attributes of a claim could be composable by having each attribute individually signed, for example. Of there could be combinations of attributes that are grouped and signed as a collection. There are a lot of ways to skin this particular cat. > > -- > Ian Jacobs <ij@w3.org> http://www.w3.org/People/Jacobs > Tel: +1 718 260 9447 > > > > -- -Shane
Received on Monday, 14 March 2016 04:27:11 UTC