Non-transferable use case

[David-Chadwick]

this adds example uses of the non-transferable property

---

Preview | Diff

[TallTed]

This is not common US English usage of proceeding, and I am not sure what is intended by it. (The sentence also lacks a closing ..)

[David-Chadwick]

I think preceding was intended.

[TallTed]

The list items that follow E.1 Non-transferability of credentials are not actually use cases, but are observations of literal text found in the physical wild, today. As far as I can tell, the use cases served by this literal text are all applications of business logic, and neither this literal text nor a property to which it may be converted belongs in the VCDM.

[Sakurann]

I think it would be useful/helpful if it would be described more explicitly why in certain credential types non-transferability is valuable, in addition to what kind of credentials have that property.

[David-Chadwick]

To give you a definitive answer, one would need to ask the existing issuers of plastic cards as to why they inserted this property onto their cards. The fact that they do is not in dispute.
One can hypothesise as to the use cases by looking at the specific cards that have these properties. In the case of my historical cathedral card the intended use case is that only the card holder should be able to enter the cathedral free of charge and that the original card holder (i.e. the issuee) should not give the card to anyone else. In the case of credit cards the use cases are self explanatory: only the subject of the credit card is authorised to use it anywhere where the card can be used.
Does this help?

[jandrieu]

@David-Chadwick This is a use case I think we should get into the document, but we have a couple requests.

First, can you pick a specific instance of use and write it up in language similar to the other short use cases? Describe a scenario for a specific person using a credential with non-transferable property, rather than listing a number of possible variants.

Second, once you have a specific instance of use, it will likely fit well into one of the existing domains. For example, your shopping card example would fit under Retail while the credit card example would fit under finance.

[David-Chadwick]

No problem. I have a few plastic cards with this property. I will choose the Canterbury Cathedral one to write up first. But which domain does this fit in? It is actually a credential for a local church member to enter a historic tourist site free of charge. I think legal identity is probably the nearest fit, since a Church of England vicar verifies the subject's identity.

I have also added the shopping example to Retail.

Finally I have removed the Generic section (although I think this is the wrong approach since Non-transferable is a generic type of use case.)

[KDean-GS1]

The challenge with the concept of a non-transferable credential is that it is usually non-transferable within the context of a specific use case. For example, my passport is non-transferable when presenting myself for entry into a country, but I can transfer my passport to my wife who can present it on my behalf to a travel agent when booking a trip.

In the case of a membership card, it can be argued that the none of the membership cards for a particular club are transferable; that would be enforced by the business logic of whichever club has issued the cards and not by the VC ecosystem itself. At best, a standardized attribute could trigger a warning to the user, but it would be hard to distinguish between a presentation for the purpose for which the credential was issued and a presentation for a transfer to another wallet.

[jandrieu]

@David-Chadwick two requests for getting this merged in.

1. Remove the author bits. We need to update all of that and will do so at the end after a discussion with the WG about how editorship and authorship should be defined.

Instead, please add a credit section to the use case itself. I'll put an example in a review.

2. Pick one of the two. What we are looking for is the one best example that shows the benefit of this particular feature. I know of the rest of the set, we have a lot of examples that are structured largely the same. We'd like to move beyond that to have use cases that more clearly differentiate their unique requirements and fewer that essentially show the same mechanism but just in different contexts.

[jandrieu]

This is getting better. Mostly let's pick the best one rather than have two that are effectively the same functionality.

[jandrieu]

Suggested change

	{ name: "David W Chadwick", url: "https://www.linkedin.com/in/davidwchadwick/",
	company: "Truetrust Ltd", companyURL: "https://truetrust.co.uk/" },

We'll update this later. For now, add a credit line as I'll demonstrate in another comment.

[jandrieu]

Suggested change

	</dd>
	<p class="shortUcContributor">Contributed by David Chadwick</p>
	</dd>

Feel free to change to your company, if you prefer.

[jandrieu]

Suggested change

	</dd>
	<p class="shortUcContributor">Contributed by David Chadwick</p>
	</dd>

Pick one of these two use cases, with the credit line, and I think we'll be good to accept.

FWIW, we like the shopper more than the tourist, as it feels more accessible.

[David-Chadwick]

Ok. I will keep the CostCo example.

[KDean-GS1]

Bona fide shopper moved to #145. Will close at a later date.

[jandrieu]

@David-Chadwick Let us know if #145 works for you.

[David-Chadwick]

#145 seems to be formatted wrongly as none of the use cases are visible in the Diff version

[jandrieu]

@David-Chadwick We merged in the other PR that we think addresses this by adding R4 Bona fide Shopper

Let us know if that works for you.

[KDean-GS1]

#145 has been pulled into main. This one will be closed in a week.

[jandrieu]

Closing per #127 (comment)