RE: About credential transfer mechanisms

Hi guys,

Read this interesting use case and the active suggestion from the community makes me wonder if this framework we have might be useful for it.

The gist of our framework is that we use a combination of verifiable credential (VC) and NFT together.
The VC is used to record any data.
The NFT is used to track the ownership.

Currently our use case is mainly on electronic bill of lading (eBL) as you might imagine, an issuer issues the document that indicates the holder and owner.

With the framework, two things happen:

  1.  Document is issued as a VC documenting information of the vessel, value of the cargo.
  2.  NFT is minted on the blockchain that capture the holder and owner.

If you keen to find out more, you can visit:
https://docs.tradetrust.io/docs/topics/introduction/transferable-records/overview


We are also open to suggestion to ideas that you might have to improve the framework!

Cheers,
Hendry

From: Joe Andrieu <joe@legreq.com>
Sent: Wednesday, May 15, 2024 4:30 AM
To: Markus Sabadello <markus@danubetech.com>
Cc: public-credentials@w3.org
Subject: Re: About credential transfer mechanisms

I would be careful using VCs for proof of ownership.

While a VC could reasonably represent a statement by, e.g., a county recorder, memorializing the title for a given property (real estate, cars, etc.) at a given point in time.

However, VCs themselves do not deal with transfer semantics, so you'll want to be very careful when assuming that a VC represents the current owner within the boundaries of the recorder's process. That is, if it takes the DMV 72 hours to update title records for a vehicle, then you can only know "who the owner is" if it hasn't changed in the last 72 hours.

Often that is enough.

But sometimes you might consider using VCs, on their own, to manage transfers or sales of VCs.

Markus's idea of transferring control of a DID to a new owner can functionally get you to an end state you desire, but you'll lose key protections in the interim. Specifically, there's no mechanism to keep me from giving multiple parties "control" over the DID, even simultaneously. So I could sell a VC to multiple people within a time window and create a race condition about who actually "wins" the race to assert ownership, in Markus's example by rotating keys again to ensure that exclusive ownership is restored.

In general, I'd avoid this kind of transfer via key rotation. Key rotation is NOT designed for that function. Nor were VCs designed with atomic ownership transfers in mind.

Instead, if you have a transferable asset, I'd recommend representing the title to that asset in an NFT and use literally any NFT platform to manage the double spend problem.

-j

On Mon, May 13, 2024 at 12:08 PM Markus Sabadello <markus@danubetech.com<mailto:markus@danubetech.com>> wrote:

Another idea:



Don't use credentials at all, just create a DID that identifies the product, and whoever holds the DID's private key is considered the owner.

You can "transfer" the product by updating the DID's controller keys to keys belonging to the new owner.



You can still have additional properties (like a GTIN) inside the DID document, or you could even have credentials about the product.



The DID doesn't change if the owner changes, i.e. the product's identifier is persistent.



You can reference earlier versions of the DID document using versionId and versionTime parameters.



Of course you'd need a DID method other than did:web (since that isn't controlled by keys) and other than did:key or did:jwk (since those can't be updated).



Markus


On 4/24/24 10:11, Ismael Illán García wrote:

  *   Greetings CCG,
  *   I would like to get your opinion on the transfer/cession of credentials. Assuming, for example, that a credential issued by a store represents product ownership similar to a purchase receipt. The credential would contain information to identify the product (e.g., GTIN) and the owner's DID. In the event of a resale, what mechanisms could be established? In my group, we have raised the following options:
  *   1. Utilizing the extensibility property of credentials: The current holder could issue a new transfer credential with their signature, which would reference the first credential. The new owner could then present the chain of credentials from them to the store that sold the product. The main problem with this approach is that previous owners could continue to present their ownership credentials as if they were still the owners.
  *   2. The other option would require the participation of the store: Once the first sale of the product has been made (store -> customer). The current owner could request the store to issue the credential again, but for the new owner's DID. To ensure that the current owner does not keep their credential and continue to use it, the store could have a published list of credential statuses, allowing them to revoke it.
  *

  *   Thanks

  *   Ismael.

  *
  *
  *
  *
  *
  *

  *