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>
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.
>    -
>    -
>    -
>    -
>    -
>    -
>    -
>
>