In use case E.1 Digital Transcript (https://opencreds.github.io/vc-use-cases/#education), Joleen is spearheading the concept of a 'extended transcript' - My question is about the "basic transcript" - and how it's a model for any issuer tracking collections of evidence that may or may not be in a hierarchy.

In the simple university case, there is a hierarchy of achievements from coursework -> exams (grade) -> course completion -> degree. In general, issues decide how their claims can be represented in the marketplace. Focusing on the top 2 levels for a moment.

A university issuers, issues a VC for the "degree" with course completion as evidence, as a result:

1. Holder can share all data in the claim
2. Holder can share only the degree w/out evidence (is this a new claim w/out evidence?)
3. Holder cannot decompose the VC and share only 1 of the courses

-- Is Item 2 above the sort of thing we envision in 4.2 Assert Claim (https://opencreds.github.io/vc-use-cases/#assert-claim) where the holder can restrict the amount of information exposed?
-- Can the university require the full detail of the evidence anytime the claim is used?
-- If the exam was a distinct VC that included both score and grade as attributes, would we expect the issuer to be a able to mandate one as optional (like score) and one required (like grade)? This implies that issuer could mandate both attributes as required, thus restricting what the Holder can withhold.

How is guardianship established in travel with minor case? Is it required for this use case?

I couldn't find any of these use-cases.

• Person is a member of a AirLine frequent flyer club
• Person is a retail loyalty program member
• Person is a Yacht Club member which provides access and benefits
• Person is a motoring club member which provides discounts at particular travel providers (accommodation, themeparks, etc.)

"Leveraging variable degrees of pseudo-anonymity per requirements of the payment transaction."

Source: https://web-payments.org/specs/FCGS/use-cases/2014-11-29/#credentials

I'm trying to map my expectations of how we issue and validate professional credentials into the documented use cases, and I think we have a gap. UC C.4 https://opencreds.github.io/vc-use-cases/#professional-credentials implies what I'm thinking, but I'd like to express a use case that's centered around the individual's process for collecting and curating their own data.

This process would bridge several of these categories of use cases. In C.4 we state that Jessica "has a variety of digital claims" but none of the uses cases suggest how that came to be and interacting with the credential repository is pretty ambiguous. I'd like to add a use case in this area. A repository is likely to serve the "whole individual", storing claims that speak to a combination of education, forma professional credentials, professional training, legal identity, interests and hobbies, etc.

I'd like to see explicit use cases that deal with this tactical exercise of an individual managing their portfolio -- adding, removing, maybe even generating bundles of claims for sharing and validation.

Is this a new category? Anyone else think this would be a useful add?

Use-Cases for Privacy / Dignity (and/or user-stories, et.al.) required.

Sec 5.1. Expansion 4 reads:
“They are satisfied, so the issuer generates a Verifiable Claim for Jane that includes information about her identity linked to their own trusted credential.”

I’m not sure why ‘credential’ is in italic here: I suspect it’s an accidental holdover from earlier drafts. I suspect it should be either plain text, or plain text with underline and link.

Inconsistent capitalization of the same words is happening throughout the document in different places, eg., at various points I saw: verifiable claims, Verifiable Claims; credential repository, Credential Repository; Needs, Sequences; needs, sequences.

This affects readability and sometimes comprehension, because capitalized words are expected to be specific, and non-capitalized words non-specific. For example, the United States has a president (no cap), who presently is President Obama (specific, cap). Thus a Verifiable Claim is expected to be a different thing than a verifiable claim. If it’s not actually different, then it’s unnecessarily confusing to the discerning reader, who may try to figure out a non-existing difference between the two versions.

I believe the best method of fixing this is to make a decision one way or the other (ie, all general uses in lower case), and do a find-replace.

(Aside: In my experience, this should not be done by a global change because there are sometimes odd instances with plurals or parts of other titles. It’s best do a ‘replace/find next’, looking at each one to make sure. For instance, the “Verifiable Claims Task Force” instances should remain all capitalized, since it’s a specific entity, so a global change to lower-case ‘verifiable claims’ would create errors there.)

It’s common in programming and Internet to do this (use a hyphen instead of a dash); I think it's a holdover from the time when true dashes weren’t available with certain keyboards. But in a formal document like this I don’t think it’s appropriate.

Here’s list of places I’ve found needing a hyphen changed to a dash, or, in some cases, to a comma or another word.

Sec 3.1 “to confirm her identity - a so called…”
Change the hyphen to dash, and also ‘so-called’ needs a hyphen.
So change to: “to confirm her identity—a so-called…”

Sec 3.3 H.4, “He further marks the disclosure as expiring in 30 days - he does not want his information verifiable after that time.”
Change to: “in 30 days—he does not want…”

Sec 3.5 C.6, “ ...she has attached her education credentials - college degree, additional specific software training, etc.”
Hyphen could be replaced with either a dash or a colon, ie: “ ...she has attached her education credentials—college degree, additional specific software training, etc.” or: “...education credentials: college degree,…”

Sec 5 “Again - please remember”
Hyphen replace with either dash or comma:
“Again—please remember…”
“Again, please remember…”

5.1 “a user will request a Verifiable Claim - a confirmation of their identity”.
Replace hyphen with ‘as’ (or possibly dash):
“a user will request a Verifiable Claim as a confirmation of their identity…”
“a user will request a Verifiable Claim—a confirmation of their identity…”
I think the ‘as’ is a clearer meaning.

5.1 Expansion 10. “The UA shows Jane her claim collection - confirming everything she has available.”
Replace hyphen with comma, possibly dash:
“The UA shows Jane her claim collection, confirming everything she has available.”
“The UA shows Jane her claim collection—confirming everything she has available.”

Imported from data model issue w3c/vc-data-model#70:

Originally posed by @David-Chadwick :

As pointed out in the section "Bundling of Dependent Claims" the bundling might be done by the holder, when the issuer is happy to issue separate credentials (e.g. to support minimum disclosure). However we need to ensure that the holder does not bundle together separate credentials that were not meant to be bundled together (as in the example of the university issuing Staff member in Dept Computing and Student in Dept Economics as 4 separate credentials).

One solution to this problem is to provide a group ID with properties that belong together in a credential. If the credential is atomized, each individual property would contain the group ID. In this way, when the holder bundles together a set of credentials and sends them to an inspector, the inspector can immediately tell which properties belong together and which do not.

This will require a change to the syntax of properties. Currently a property is defined as a name-value pair. But if a property is defined as a set of attributes and a group ID, each of which are name-value pairs, then the inspector can easily link together the properties of complex credentials.

Viz: in general a property would be:

“property”: {
"attributeName": "AttributeValue", ----- one or many
"groupID": "groupValue”
}

For example if the university in the example above issued two VCs to the person, they would contain the following properties:

“property”: {
"status": "Staff",
“dept:”: “Computing”,
"groupID": "12345”
}

“property”: {
"status": "PG Student",
“dept:”: “Economics”,
"groupID": "98765”
}

If the university now atomized the properties, and issued four VCs, they would contain:

“property”: {
"status": "Staff",
"groupID": "12345”
}

“property”: {
“dept:”: “Computing”,
"groupID": "12345”
}

“property”: {
"status": "PG Student",
"groupID": "98765”
}

“property”: {
“dept:”: “Economics”,
"groupID": "98765”
}

Now when the holder bundles them together, the inspector can tell if the credentials are related or not.

3.2 E.1 “Upon the request of her students Joleen issues digital credentials that encapsulates an extended transcript,” is hard to read with mismatched singular plural.
Either make both plural:
“Upon the request of her students Joleen issues digital credentials that encapsulate an extended transcript.”
Or both singular:
“a digital credential that encapsulates…”

And, a separate issue with the same clause:
Perhaps ‘encapsulates’ is too detailed; maybe just use “includes” ?
ie
“Upon the request of her students Joleen issues a digital credential that includes an extended transcript.”

The charter calls out three use cases that should be added to the Needs Map:

• Loyalty programs
• Digital offers
• Digital receipts

We did a heap of work on use-cases which were broadly stripped down prior to the formation of the credentials CG.

Some old links include:
https://lists.w3.org/Archives/Public/public-webpayments/2014May/0079.html
https://lists.w3.org/Archives/Public/public-credentials/2015Jun/0018.html
Food Supply Chain Mapping: https://lists.w3.org/Archives/Public/public-webpayments/2015Jun/0044.html (health and safety)
https://lists.w3.org/Archives/Public/public-credentials/2015Aug/0021.html (birth/death/marriage)
Giving to things to homeless / vulnerable / start-ups: https://lists.w3.org/Archives/Public/public-credentials/2016Feb/0069.html

Privacy: https://lists.w3.org/Archives/Public/public-webpayments/2014Jul/0003.html --> https://lists.w3.org/Archives/Public/public-webpayments/2014Jul/0043.html
Interoperability with WebID https://lists.w3.org/Archives/Public/public-webpayments/2014Jun/0124.html

"Neither TURTLE nor JSON-LD should be mandated in any RDF based spec. RDF is a Language associated with many notations."
Source: https://lists.w3.org/Archives/Public/public-webpayments/2014Jul/0083.html

Hi. Maybe this issue is caused by my poor english, but I find "Holder" a slightly confusing term as it is not very clear to me, what "to hold a claim" could mean in this context. May "Claimer" be a better word here? Or maybe someone could come up with even more definite term?

As title:
Section, Status:
Should reader be directed to Github ‘issues’ link as well as to the mailing list?

In terms of the data-model, storage is almost certainly out of scope. However, if storage as a use case needs support somehow in the data model maybe we should include it.

The recent round of terminology discussion boiled down to three key actions

• issuing credentials
• presenting profiles
• verifying credentials and profiles

In particular, nothing in the conversation seemed to vary based on where the claims are stored. Rather, they should be able to work wherever a claim might be stored.

If there is something different based on the location or method of claim storage, we should unpack that, but I expect that isn't what we're striving for.

This suggests that the protocol-level aspects of storage may be out of scope at this stage.

Discussion?

In issue # 12 of the VC-Data-Model @agropper wrote:

Privacy engineering can help sort through the different aspects of privacy in a use case. I’d like to relate this issue to the specific prescription use case that I maintain.

The highest privacy goal of this use-case is to maintain the self-sovereignty of the physician-patient relationship in the face of regulatory requirements. Specifically, we seek to enable a transaction system for a prescription that does not depend on institutional trust as an identity provider for the physician and the patient together. The privacy benefit is the ability for the physician and the patient to interact without having that interaction monitored by an intermediary institution such as a hospital. This opportunity for an un-mediated patient-physician relationship was common with paper prescriptions and has been lost in the transition to electronic health records.

In order to achieve this privacy goal, the role of the hospital intermediary as a combined root of trust for patient ID, physician ID, physician attribute, and transaction auditability needs to be distributed among various substitutable actors with a minimum of correlation risk across the actors.

Working backward, the physician claim must be verified against a directory operated by an issuer that has no role relative to the issuance of the physician ID or any role whatsoever relative to patient ID. The reason for this is that the directory operator does not want any responsibility for security breaches of any patient information and has no interest in sharing an identity provider used by the patient. For the physician ID, the directory provider does not want to bear responsibility for identity proofing the physician. Cost-effective operation of directories requires they trust identity providers. The directory operator is merely a relying party, using whatever identity the physician chooses. The federation implied by the physician’s IDP is responsible for identity proofing to a level adequate for prescribing controlled substances per DEA and access to patient records under state and federal privacy mandates.

The physician ID used to maintain the physician claim must be non-repudiable and able to:

Sign updates to the physician directory operated by the issuer prescription in an auditable way (e.g.: associated with a blockchain timestamp).

Sign a prescription for a specific patient in an auditable way.

The patient identity (but not necessarily the patient ID) captured in the prescription and presented to the pharmacy must be correlated in a non-repudiable way. The pharmacy transaction must be auditable.

The pharmacy must be able to verify the physician claim in a way that does not allow the pharmacy to correlate other transactions by the same physician. (The sale of physician prescribing info has been challenged in high courts and is allowed as free speech by the pharmacy. This causes a lot of privacy problems for the physician and the patient. It is the primary source of the huge data broker market in healthcare.)

The physician must be able to report the transaction to a (law-enforcement) registry that can track patient identity across different physician-patient relationships and physicians must be able to query this registry prior to issuing a prescription. The registry itself, as a law enforcement function, can have access to the identity of the physician and the patient. (These state-operated registries are called prescription drug monitoring programs.) The pharmacy must be able to verify that the prescription was reported to the registry (to keep the doctors honest). The pharmacy may have it’s own law enforcement registry reporting requirements but these are outside the physician-patient relationship privacy engineering issue.

Note that in most, maybe all, states, the pharmacy can deliver a prescription to the physician for the physician to distribute to the patient. In this somewhat inconvenient way, the privacy of the patient relative to the pharmacy can be absolute.

This issue moves my (@jandrieu) response to this use case repo:

Thanks for the example, @agropper. It's a solid example of where Verifiable Claims can help with privacy.

To help us move towards a more rigorous lexicon, I'd like to call this a "use domain" instead of a "use case." I'm hoping to establish a specific semantics for use cases:

A use case defines a specific value-creating transaction between an individual and the system.

A use domain defines a related set of use cases.

I'm still working through the best alternative language, but "use domain" or "domain of use" seems like a good way to describe this example, which include several transactions, as well as domain-specific non-functional requirements, such as both the correlatability and non-correlatability you outline.

From what I read, I tease out a few different transactions:

1. Issue prescription
2. Verify prescription
3. Present prescription
4. Audit pharmacy
5. Register prescription

There may also be transactions related to the credential that enables a doctor to prescribe as well as recording pharmacy interactions: requesting fulfilment of a prescription, fulfilling a prescription, etc., so we can understand the needs of the audit. As with many of these kinds of use, the trick is defining the coherent boundary so we can focus on the new and interesting bits. For example, one could discuss how all of the entities in the domain provision their credentials: the monitoring agencys, the pharmacies, the pharmacists, the insurance companies (surprisingly missing from your example). Clearly, taking some of these entities (and their credentialing) as a given greatly simplifies the documentation.

To try and tease out the correlatability:

Intended correlations:

1. The live person redeeming a prescription needs to be correlatable to the patient for whom the prescription was given, by the pharmacist, prior to distribution so that the medicine is given to the actual patient.
2. The patient needs to be correlatable to a singular legal person by the prescription drug monitoring program for the purposes of assuring that individuals are not getting multiple prescriptions by visiting multiple doctors. The physician needs to be able to query the program prior to issuing a prescription.
3. The physician and patients need to be correlatable across multiple prescriptions for physician audits.
4. A given prescription must be resolvable to a delivery address while preventing the pharmacy from correlating the doctor to the prescription. This resolution must be non-repudiable.
5. Upon delivery, a prescription must be correlatable by the issuing doctor to the patient

Blocked correlations:

1. The pharmacy must not be able to correlate the physician's prescriptions across different patients.
2. Someone who is not the intended patient must not be able to redeem a prescription (must not be falsely correlated as the patient).
3. The prescription may be redeemed at any pharmacy. There is no innate correlation between a given prescription and the pharmacy that fulfills it.

Do these transactions and correlations seem correct?

Questions:

1. If I assume for the sake of discussion that all of this information is stored in an effectively public repository--this assumption addresses both public ledgers and compromised data stores--then can we assume that certain information is encrypted for the intended recipient? For example is the prescription delivery address encrypted for a specific delivery service?

2. For correlation 3, who is doing the audit? How do we allow an audit without allowing the pharmacy to perform the same correlation? Are there baked in assumptions about where "auditable" data is stored that can be trusted to be secure from the Pharmacy? I don't think we care about pharmacies that are bad actors willing to hack a physician's database. For this use domain, it might be valuable to identify a strawman architecture that distinguishes who holds what data. I'm assuming that the monitoring program and the physician both have private data stores for audit purposes, while the rest of the data could be stored in a self-sovereign public ledger. (If insurance is involved, the pharmacy will probably need its own data store as well.) Or... is there a way that all of this information could be in a public data store?

3. For correlation 2, are we trusting the monitoring program to operate a secure, live system? Or is the goal to have that monitoring (and the doctor's query) based in a public ledger? In other words, along with question 2, can we clarify where, for this use domain, we need to trust a system (and its operator) with certain information and which systems we choose not to trust with certain information?

4. What about insurance companies? Are they an important part of the privacy engineering?

5. Does the pharmacy need to verify that the prescription has been registered with the monitoring program?

Final paragraph of 1.2 reads:
“As with all models, this use case model is neither exhaustive nor complete. The listed uses cannot exhaustively capture all possible use cases. Similarly, the models do not completely characterize the use cases represented. However, the combined model provides specific, coherent guidance for the work ahead.”

To me, the final sentence, “However, the combined…” could be read as too certain, and hence possibly slight bragging, which is distracting. I propose a change to intention rather than certainty:

“However, the combined model is intended to provide specific, coherent guidance for the work ahead.”

As well, the repetition of ‘exhaustive’ at the beginning of the paragraph seems unnecessary and...exhausting…;-) . I’d prefer cutting the second instance of the word. So the amended paragraph as a whole would read:

+++++
“As with all models, this use case model is neither exhaustive nor complete. The listed uses cannot capture all possible use cases. Similarly, the models do not completely characterize the use cases represented. However, the combined model is intended to provide specific, coherent guidance for the work ahead.”
+++++

Sec 4.4 Store/Move claim: confusing “Motivations”

I believe major editing is necessary of the Motivations and Requirements sections of 4.4.
A revised text is proposed after my reasoning.

The reasoning:
It’s clear from the first sentence that the motivations we’re talking about should be those of the Holder, but some motivations listed in the end of the Motivations section are not those of the Holder: the terms “business intelligence”, “competition in this space” and “foster innovation” are not things that the Holder need know or care about, in general. The Holder may care about cost or service levels, but that’s about as far as it will go. So, much of the paragraph is apparently from some other business-analysis point of view; not the Holder’s Motivation.

Plus, I believe that one of these ‘motivations’ (the ability to migrate the claims among different repositories) is actually a requirement, and should be moved to the Requirements section.

Taking the two issues together, I suggest changing the 4.4 Requirement and Motivation sections to read as follows:

+++++++++++
Requirement:
It MUST be possible for the holder of a claim to store that claim in one or more credential repositories. It MUST also be possible for the holder to move a claim among credential repositories, and to do so without requesting a new claim from the claim issuer.

Motivation:
A claim is under the control of its holder. That holder will choose where their claims are stored based upon a variety of factors (e.g., employer requirements, convenience, service levels, provider cost).
+++++++++++

There have been a few additional use cases proposed recently, on top of the years of work exploring and distilling use cases down to a coherent set. As more people join the group (which I expect will happen once we being a working group), even more people will have their favorite use case they wish were included.

On the one hand, I want us to be able to embrace the vast world of possible applications. On the other, I have repeatedly found it productive to focus attention on a limited number of "focal use cases", as discussed in #19.

The system-wide set of adopted use cases is represented in the User Needs Map, highlighting key use cases in the most resonant domains. The key isn't to capture EVERYTHING, but rather to say, these domains as represented in these use cases are the most representative of the distinct value of Verifiable Claims. My primary filter for that diagram is keeping it on a single page yet not an "eye-chart" that's so complicated it becomes an effort just to read it.

First, not all of those User Needs use cases are well-formed. For example, the "Refugee Crisis" use case (which I proposed in the wake of ID2020) is not a single value-creating transaction. It's more of a domain of potential use cases than a single one. We should fix that.

Second, there are outstanding proposals to add new use cases. I'd like to consider such additions in a coherent way, with a set of criteria that proposed use cases must meet for consideration. Any contribution that isn't a rigorous use case but anchors our work in real-world examples can be listed separately #20.

Suggested criteria:

1. Single transaction with the system that creates value for an individual
2. Memorable name
3. Action/Reaction pair
4. Described in concise prose paragraph (Scenario)
5. Describes a distinctive use enabled by verifiable claims

I think we should also consider an upper limit. There are currently 25 User Needs which map to 8 User Tasks. I'd like to keep that under 30-35 User needs and no more than 10 User Tasks. Even looking at those numbers, less is more.

Is there a good process we could use for evaluating and selecting potential new use cases?

Typically, after documenting use cases, these are used to establish requirements which can then be referenced back from the specification to determine that given requirements have been satisfied. Requirements are also useful to capture the commonalities between different use cases.

The CSV on the Web: Use Cases and Requirements document is one example of how this can be done.

3.2 E.3 reads:
“Rocky is an undergraduate student at Wossamotta U. His school provides a credential repository service to all students and alumni, so he chooses to use it. In his third year, Rocky decides to transfer to Moosylvania Tech. They do not offer a service, but he does not want to continue to use the service of his old (and now rival school) so he moves his claims to the service offered by his bank without needing to have them reissued.”

First, I’d prefer the Wossamotta U. and Moosylvania Tech be changed to something less distracting. It’s fun, but the rest of the document doesn’t match the informality of this section. Perhaps “Citycentre U.” and “Anothertown Tech”.

However, even if that’s not done, I find it hard to stomach the formal “do not” and “does not” here, i.e., without the usual contractions. And especially if this example is supposed to be light and breezy (“Wossamotta, U don’t like this example?), the formality is jarring.

So combined, I’d suggest the paragraph becomes:

++++
“Rocky is an undergraduate student at Citycentre U. His school provides a credential repository service to all students and alumni, so he chooses to use it. In his third year, Rocky decides to transfer to Anothertown Tech. They don’t offer a service, but he doesn’t want to continue to use the service of his old (and now rival school) so he moves his claims to the service offered by his bank without needing to have them reissued.”
++++

A merchant cryptographically-signs a standardized offer for a good or service. A buyer purchases the good or service from the merchant resulting in a standardized, cryptographically signed, machine-readable, digital receipt that is issued to the buyer. Entities involved in the transaction (merchant, buyer, payee) may then use the receipt as a proof-of-purchase for the good or service.

source: https://web-payments.org/specs/FCGS/use-cases/2014-11-29/#credentials

Below, two typos preceeded by question mark (?)

3.1 Finance
a high value placed on ?knwoing exactly with

L.4 Refugee crisis
just across the ?broder

At https://github.com/w3c/vc-use-cases
it links to https://opencreds.github.io/vc-use-cases/
It should link to https://w3c.github.io/vc-use-cases/

@msporny I believe you know how to fix this.

Person has a claim that allows them to obtain a specific deal or product in exchange for the credential.

• multi-use
• one time only
• et.al.

Sentence in Sec 5:
“The transaction examples in this section basic ways in which Verifiable Claims might be used.”

Suggest adding verb ‘show’:
“The transaction examples in this section show basic ways in which verifiable claims might be used.”

Providing a printable identifier that can be used in retail products (ie: clothing). This has a number of functional benefits including means to ensure the purchased product is authentic.

https://lists.w3.org/Archives/Public/public-webpayments/2014Sep/0099.html

I'd like to suggest rewriting Section 5 User Sequences to instead use Constantine & Lockwood's Essential Narrative format. Not only should this avoid some of the dependence on architectural assumptions, e.g., user agents and credential repositories, but it would help clarify the flow of the user experience independent of the underlying technology.

Here's a strawman example of Issue Claim as an Essential Narrative. Note that although the claim is issued by the Issuer, it is the Holder who drives the interaction:

This particular flow illustrates some questions I have.

First, authenticating the user is optional and its order may vary. I think the most common case is logging in to the website first with username/password, then asking for the credential, but it seemed more inline with the use case to start with the intention as getting the credential. There is agreement that there is no requirement for the issuer to authenticate the user, correct?

Second, "credential repository" is listed a "a storage vault or ... wallet that stores and protects access to ... credentials and verifiable claims" However, this confusing to me.

Neither the use cases nor the data model present any language about blockchain or ledgers, and yet my understanding is that a public ledger is key to the notion of self-sovereign identity and therefore, key to Verifiable Claims. I understand that we are NOT specifying protocols at this stage, but am I correct that there is an unstated expectation that claims are stored not just directly in a filesystem or database, but in a ledger and then reference in a wallet?

Third, does moving a claim mean moving it from one wallet to another or from one ledger to another? There is currently no distinction between substitutability of wallets and substitutability of ledgers. It seems to me that if we don't ensure portability between ledgers we don't really have portability. Is it currently expected that one may move a claim from one ledger to another? If so, how does that work for revoking and/or amending claims?

Sec 2, “Holder” reads in full:
“The entity who controls a particular claim. Often the subject of the claim, but not always. For example, the subject of a claim might be a pet who has received a vaccination. The holder of that claim is likely the pet's owner, not the pet. A holder is typically the initiator of the transmission of a claim.”

The second sentence, “Often the subject of the claim, but not always” might be slightly confusing, since the subject is omitted again. It is also omitted in the first sentence, but that’s implied to be Holder by proximity to the title; by the second sentence that proximity is weaker.

I suggest adding that subject to the second sentence, so the first two sentences would now read:
“The entity who controls a particular claim. The holder is often the subject of the claim, but not always.”

or possibly maintain the same wording but use a semicolon, which would maintain the connection with the “Holder” title:
“The entity who controls a particular claim; often the subject of the claim, but not always.”

In 2010, Jack got his first job, which he worked at for 6 months. He was unemployed for 2 months and then got another job for a short-time, before enrolling in university to become a computer scientist.

In late 2015 he had a few problems and obtained social-security. The government decided to 'crack down' on welfare fraud, and sent jack a letter stating that he may have been earning money when he was obtaining their support (because they're not quite sure, they got an annual figure from the tax office and then equally spread that figure across the year). Jack never kept his payslips and unfortunately now - the business he worked for doesn't exist anymore (he thinks maybe they were unable to pay their tax bill so shut the company down and started a new one somewhere else).

Jack needs a digital payslip provided for him so that he can assure the government that he is a good boy and was not in fact one of those bad people they're trying to track down and keep honest.!

other unrelated yet similar sorts of use-case examples;
http://www.news.com.au/finance/money/costs/aussies-panicking-over-centrelink-demands-to-pay-up-to-avoid-debt-collector/news-story/a13ba2f6090aecc7152b5ceb65166315

"Last week the department quietly changed advice on its website requiring welfare recipients to keep evidence of income including pay slips for six months."

The advice now requires evidence of income to be kept indefinitely.
http://www.illawarramercury.com.au/story/4396225/they-dont-care-about-average-australians-centrelink-staffer-speaks-out-about-debt-controversy/?cs=7

Sec 3.1 Typo “knwoing” First sentence:
“knowing”
Sec 3.6 L.2 Typo “the” should be “they”
“Once they are satisfied, the[y] will...”

By charter, the use case document needs a section on gap analysis.

Alice goes to her doctor (or domestic violence safety firm) complaining of harassing phone calls and breaches to a safety order. She provides authority for the GP to make a Telecommunications metadata request (or indeed one via Facebook, Google, Apple, Microsoft, etc.) to identify if data exists to support her claim. The doctor lodges the request, gets the results.

1. information is false - data exists and the problem is not occurring by way of what is known.
2. information is correct - doctor provides advocacy to support the wellbeing of Alice.

the github.io link in the header of this repo still references opencreds. should reference w3c:

change https://opencreds.github.io/vc-use-cases/
to https://w3c.github.io/vc-use-cases/

Consider for example, creditworthiness. A subject may have credit cards in many banks, and the banks may not be in the position to exchange information about the subjects they issue credit cards to. It may be in the bank's best interest not to do so, as it would reveal too much of the competition situation to rivals, and it may be in the subject's best interest not to do so, to not reveal information about themselves. In some jurisdictions, it may even be illegal to gather such information.

Thus, creditworthiness may be difficult to prove or assess.

Now, I think it would be very interesting if a subject could aggregate all outstanding debt without disclosing which bank (now in the issuer role) or how much debt they have in each back. The aggregate should be verifiable by the bank (in the inspector role), without each issuer being known.

This has several components: It must be possible to ensure that the ground data was verifiable, it must be possible to ensure that data was not modified before aggregate, it must be possible to verify that the
aggregation operation itself was correct. Finally, aggregation implies a closed world assumption, which is in the general case impossible to verify.

This last problem is interesting, but in practical cases, it should be possible to address. There is a finite number of banks, closure could be made by using a shared and trusted exhaustive list of issuers.

Now, it would be neat if there's some cryptographical way to ensure all of the above (except closed world), so that only the current user roles need to be involved. I'm not well versed in that literature though, so I'm
assuming a trusted third party would have to be involved to verify the ground data and perform the aggregation, and then sign the aggregation.

As title.

An entity (payer, payee, merchant, buyer) stores wallet, credentials, and digital receipts with a particular identity/wallet/data storage provider. The entity decides to switch to a different identity/wallet/data storage provider and all wallet, receipt, and credential data comes with them.
source: https://web-payments.org/specs/FCGS/use-cases/2014-11-29/#credentials

Feedback on: https://w3c.github.io/vc-use-cases/

There is a requirement to sometimes dispute Claims (from any entity) in cases where this is disagreement about a statement.

This could be considered as a new “User Task”.

Lifecycle engagement models, based on the Customer-Supplier Engagement Framework provide a way to consider the full scope of data interactions between and individual and a potentially distributed/decentralized system over a specified "life". I'd like to present some engagement models for consideration to understand how Verifiable Claims can enable self-sovereign identity.

At the third rebooting web of trust, I led a group exercise in defining an engagement model for Joram, a Syrian Refugee. I am also working with @ChristopherA to define an engagement model for Web of Trust. These are two young for consideration today, but when they are ready, I'd like the group to consider them for inclusion.

Sec 4.2: Add to ‘Needs’: “C.5 Social Authority: Freedonia” with link to the second example in C.5, Freedonia.

In my opinion the Freedonia pseudo-anonymity is a key example for 4.2, in terms of “restrict the amount of information exposed in the claim” as 4.2 states. Pseudo-anonymity involves withholding the person’s real legal name, which is perhaps the most important piece of data that can be withheld.

The current use case document is lacking in real-world examples of verifiable claims in action. This contrasts with other W3C use case documents such as the CSV on the Web's use cases: https://www.w3.org/TR/2016/NOTE-csvw-ucr-20160225/

I recommend we gather such examples and incorporate them in the document in a new section.

Per charter, we need a section on privacy risks. Some question whether this is a separate note or not.

There seems to be a lot of "uses" and interoperability content regarding "verifiable claims". How to use. How to create. How a User Agent and End User interact regarding the "verifiable claim". Unless I'm missing something I do not see any content on registration of an individual seeking to establish their "verifiable claim" that once established, will be how an End User prefers to be identified within a particular online transaction.

This begs s simple question: What is the registration process for one to establish a "Verifiable Claim"?

Recent NIST publication SP 800-63.3a Digital Identity Guidelines Enrollment and Identity Proofing Requirements specifically addresses "Supervised Remote In-Person Identity Proofing". Are the plans to include registration solutions? And if so what standards will be applied? WIth it in mind that for cryptocurrency ERC725 seems very promising.

On Tue, Dec 20, 2016 at 11:49 AM, Shane McCarron [email protected] wrote:

We have a lot of secondary and interesting use cases that were dropped on the floor to fir into Ian's model that smaller is better. I wonder if we should look at pulling some of those in?

On Tue, Dec 20, 2016 at 12:48 PM, Stone, Matt [email protected] wrote:

...the implementation work should be driven by and support use cases. The use case doc will also provide groundwork for newcomers to understand the context of whatever decisions we ultimately make in the data model doc.
Let's drive the group to a high level of comfort that the use cases we have are good and mostly complete so we can check it off our list.

There were two or three domains that came up at the IIW/F2F meeting. I recall Chris's Web of Trust and also Heather's Military domains, but I think there was a third.

I'd like to evolve the use cases so that we have a coherent balance of breadth and depth without distinguishing "core" verses "additional", but perhaps using the term "focal" instead. There's a history of treating requirements as exhaustive specifications and one of my goals is to displace that idea with the principle that you don't need to be exhaustive as much as you need to be able to capture a consensus understanding of the scope of the system on one hand and specific instances on the other.

Illustrations of specific "focal" instances do not diminish other use cases, they simply provide the necessary level of detail within a limited scope so they are easier to follow or understand. These "focal" use cases are usually the most important, but from a process standpoint, the most important thing is that they are limited in # so you can have concise discussions about them.

Models like the Needs Map and Task Map (in the current Use Case doc) are designed to show the full scope as intended by the team. I'd like to review these with an eye to potentially adding the new domains discussed at the F2F as well as improving the current list (some of the "young" use cases are less than well-defined).

By the charter, the use case document should have a section of evidence of applicability.

H.5 Proving Legal Disability Status

Trina, who is legally blind is currently unemployed and needs to use the local free disability ride service to get to the employment office. To use this service she is required to verify that she, in fact, maintains legal disability status. Trina provides her government-issued disability credential to sign up for the ride service, and in doing so it is not necessary for her to disclose her specific disability to the ride service as it could put her at personal risk.

w3c/vc-data-model#50

We currently don't have a Web Of Trust use case for verified claims. Here is what I've written up so far, and a line for each of the twelve steps of Joe's use case engagement model.

Alice is a 1st-generation citizen of a western country (United States, Britain, Germany), born of two immigrants from a country of significant repression (Iran, Cuba, North Korea) who are now permanent residents. Her parents were settled in a small city near the agricultural heart of the county (Mid-West United States, Midlands of Britain, Saxony of Germany) where they have become successful small business owners.

As a child she was told stories of the abuses of her parents in their country of origin, where they are now not able to return. She knows some cousins and other family members in these other countries who have told similar stories, but mostly through the internet or traveling to different countries of the diaspora of their extended family.

Both Alice and her parents have experienced some unkind words and minor discrimination in their newly adopted country, but largely the benefits of being in a modern western country overwhelm any disadvantages. The parents have found others to practice their religion with, which Alice respects but in general is more secular.

Alice has recently graduated with a computer science degree, and has pleased her parents by settling nearby, working for a small regional bank. Quite conservative, they have a “no social media” policy at work — a rule which is regularly broken, but there have been some others who have experienced object lessons, especially if they stand out as non-conformists.

However, the winds of populism are blowing. Alice has personally heard more slurs lately, seen more covered the media, and many local political parties of rising significance have publicly targeted her ethnicity, her parents religion, etc. Added to the stories of repression in her parent’s birth country, even greater stories of conflict reported by distant family members, Alice has some legitimate fear.

Alice, like most millennials, doesn’t wish to leave her head in the sand—she wishes to take a more active role in making a better world. However, she knows if she stands out from the crowd that any activism she may get involved in may not only affect her, they may affect her parents or even her extended family abroad. Increasingly Alice has been more careful — self-censoring social media, using end-to-end encryption software to talk to her family abroad, etc.

Bob, a mainstream citizen of his western country, is also worried about the rising tide of populism in his own country, and extremism in other countries. Raised by a middle-class family he has travelled widely as a young adult, and has been supported by his parents to join as an employee of a non-profit organizations. Bob is not a programmer, but an active user of social media and other internet technology, and has some ideas about how his non-profit could use mobile applications to serve their advocacy. He shares his ideas out in the world in a public forum.

Alice reads this request, and has the skills to help make such a mobile applications, but now has a dilemma. She has heard of other professional women who have been public about work and have been heavily criticized or even doxxed (gamer-gate, etc.), and doesn’t want to risk her job, or risk her family by her activities. She also doesn’t have a reputation in the developer community as a mobile programmer. She also has limited time to be able to help, thus has to be focused and careful about what she can offer.

Our use case will show how Alice meets Bob anonymously to offer help with his project. How Alice is able to demonstrate and share a positive reputation for her quality work. How Carol is able to use Alice’s software to protect herself from harm in a third-world country. How Ted is able to review Bob’s ideas and Alice’s work, and offer some funding to help both. How Alice is able to increase her reputation in her anonymously developed software to the point where she is offered a job at Ted’s company that pays more than her job at a conservative bank. How she is able to selectively revoke parts of her anonymity to establish her personal reputation her peers and selective colleagues, without at any time putting Carol and her other advocacy clients at risk.

Notes:

Ref: Spocko’s Brain and the need to be free to engage politically without putting his career as a PR professional at risk.

MBA student. Female cell phone co entrepreneur. Teaching Afghani women to use technology to engage the world to build business and form social bonds. Was open and above board in what she was doing. Had to leave Afghanistan after direct conversations from Afghan “leadership” warning her she can’t continue to do what she was doing.

Iranian human rights advocacy. Roving bands of self-appointed religious zealots who have quasi-authority to enforce their interpretation of “law” on their own judgment. They will confiscate cell phones and review texts and posts, punishing women for contact with men or other “bad” behavior. (One effort included a hidey-seeky Android. Another took the waize app and modified the speed trap capability for reporting these Iranian enforcement groups. This second one has been a big success). The challenge is, they don’t want to advertise this successful technology. They fear reprisals from Iranian cyber capabilities. Since they piggybacked on Waize, it would be hard to shut it down without shutting down all of waize.

Calais refugees avoiding safe houses because of required biometric recognition. The Syrian cyber army have attacked organizations in Europe and families back home.

SS Tech may be adopted by the tech side of the world first.

Key choices:
“Alice” is British (we’ll find another name for her and for Bob).
The lifecycle is Alice’s privacy-enhancing product developed with and distributed to the Iranian underground.

Stage 1 — Seek and Availability
Bootstrapping, provisioning. Each party acting prior to contact.

Seek.

Availability.

Data Records:

Stage 2 — Approach and Reconnecting
Initiating contact within the context of the system.

Approach.

Reconnecting.

Data Records:

Stage 3 — Request and Triage
Vetting and credibility and establishing “good actor/bad actor” status

Request.

Triage.

Data Records:

Stage 4 — Comply & Direct
Insider provides direction, guidance, introductions.

Direct.

Comply.

Data Records:

Stage 5 — Consent and Provision
Guidance is followed. Permission and participation agreed to.
Consent.

Provision.

Data Records:.

Stage 6 — Disclose and Intake
Questions, information shared and recorded

Disclose
Intake

Stage 7 — Use Services and Provide Services
Collaboration
Promotion
Product distribution

Use Services.

Provide Services

Data Records:

Stage 8 — Accept Enhancement and Offer Enhancement
Additional services. Payment. Receipt of payment.

Offer Enhancement. .

Accept Enhancement. .

Data Records:

Stage 9 — Update and Maintain

Update. .

Maintain. .

Data Records:.

Stage 10 — Escalate Issue and Resolve Issue

Escalate Issue. .

Resolve Issue. .

Data Records: .

Stage 11 — Leave and Manage Exits
Job offer

Leave. .

Manage Exits..

Data Records:

Stage 12 — Re-engage and Re-engage
Request for fixes and enhancements
Re-Engage. .

Re-Engage. .

Data Records. .

somewhat inconsistent message between
5.1 How a verifiable claim might be created: UA interacts with User to display/save credentials, but
5.2 How a verifiable claim might be used: Credentials Repository interacts with User to display/select