W3C home > Mailing lists > Public > public-credentials@w3.org > February 2021

Re: ERC-721 Non-Fungible Token Standard on Ethereum vs. VCs on Hyperledger Indy

From: Adrian Gropper <agropper@healthurl.com>
Date: Sun, 14 Feb 2021 20:22:26 -0500
Message-ID: <CANYRo8jy+jh2w5LNvAq8UmMg0HFQ8-TNji84dH35EvAUp2zgDQ@mail.gmail.com>
To: Nikos Fotiou <fotiou@aueb.gr>
Cc: "Michael Herman (Trusted Digital Web)" <mwherman@parallelspace.net>, Carlos Bruguera <cbruguera@gmail.com>, Will Abramson <wip.abramson@gmail.com>, Credentials Community Group <public-credentials@w3.org>, sds-wg@dif.groups.io
Hi Nikos,

https://arxiv.org/pdf/2001.10461.pdf is a fabulous paper and bears
cross-posting to the Confidential Storage WG where we're dealing with
authorization in front of an encrypted data vault (EDV) as a resource
server (RS).

In particular, I'm concerned about the use-case where the Resource Owner
controls a wallet as a user agent (RO) which may be off-line. The RO or RQ
also control an agent / Authorization Server (AS) in the cloud that does
not have the benefit of a hardware secure module the way the wallet / RO or
RQ does. Requests are presented to the AS by the user agent of the
requesting party (RQ). The RQ is typically different from the Client (RC)
which will be used to access the RS. This is all diagrammed here:
https://docs.google.com/presentation/d/1ksKal62ZiApX09Nejm4RSqHzHJbgwpu_l2Ho64_ePKU/edit#slide=id.gb2d2b0f28a_0_0


This use-case is common in healthcare where requesting parties are
accountable as licensed individuals but also use an institutional system as
the client to deal with the wider world. Consider, for example, the
Healthcare focal use-case 6.3 Prescriptions (healthcare)
<https://w3c.github.io/did-use-cases/#prescriptions>.

   1. The doctor as RO signs an encrypts a prescription as an NFT with a
   smart contract that will allow revocation when _both_ the pharmacist signs
   that it was dispensed AND the patient signs they received it. (This keeps
   everyone involved accountable for a controlled substance.)
   2. The encryption key is shared with the patient who obviously can know
   what the prescription says.
   3. The encrypted prescription is stored with an RS anywhere the patient
   wants (patient wallet, EDV, personal data store, hospital IT system)
   4. The patient chooses a pharmacy and a pharmacist (RQ) and shares the
   prescription URI (RS), the AS URL, and the encryption key.
   5. The RQ presents their credentials to the AS and receives a JWT for
   access to the RS.
   6. The RQ passes these to the pharmacy system (RC) and dispenses the
   medication.
   7. The accepts the NFT and the contract is now fulfilled so the
   prescription cannot be reused and the ledger remains as an encrypted audit
   trail.

A second use-case may or may not be solved by your approach. We need a way
that the RO can be off-line when the AS issues the JWT. The problem here is
that the AS does not have an obvious way to store the keys it needs. A
threshold signature scheme might work if the AS and RS or the AS and a
notary / auditor both get to evaluate the RQ request but I'm wondering if
there are other solutions. The notary should not have access to the
resource content itself but should be trusted to contribute to
accountability and audit.

Adrian


On Fri, Feb 12, 2021 at 9:07 AM Nikos Fotiou <fotiou@aueb.gr> wrote:

> Last year we published this paper in NDSS DISS workshop
>
> https://arxiv.org/pdf/2001.10461.pdf
>
> We used OAuth2.0 to produce ERC-721 tokens which then were used as access
> tokens. So related to this discussion may be it will be more relevant to
> consider ERC-721 for storing zcap tokens (
> https://w3c-ccg.github.io/zcap-ld/). ZCAPs support delegation by design (
> https://w3c-ccg.github.io/zcap-ld/#delegation).
>
> Best,
> Nikos
> --
> Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou
> Researcher - Mobile Multimedia Laboratory
> Athens University of Economics and Business
> https://mm.aueb.gr
>
> > On 12 Feb 2021, at 2:53 PM, Michael Herman (Trusted Digital Web) <
> mwherman@parallelspace.net> wrote:
> >
> > Thank you Carlos and Will,
> >
> > The user scenario is one of those classic “art on the blockchain” kinds
> of scenarios …so transferability is important.
> >
> > I believe the ability to revoke a VC for the old owner of a piece of
> artwork and to re-issue a new VC for the new owner of the artwork should be
> sufficient for this scenario.  Thoughts?
> >
> > The existence of existing ECR-721 market places is an important Ethereum
> advantage: e.g. https://opensea.io/
> >
> > Thank you both,
> > Michael
> >
> >
> > From: Carlos Bruguera <cbruguera@gmail.com>
> > Sent: February 12, 2021 4:10 AM
> > To: Will Abramson <wip.abramson@gmail.com>
> > Cc: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>;
> Credentials Community Group <public-credentials@w3.org>
> > Subject: Re: ERC-721 Non-Fungible Token Standard on Ethereum vs. VCs on
> Hyperledger Indy
> >
> > Just a quick comment, ERC-721 defines an interface the token contracts
> should implement to comply with it, but it doesn't enforce any particular
> behavior, therefore it's possible to write a non-transferable ERC-721,
> still complying with the interface as long as the `transfer` function is
> provided, it would either revert or not do anything.
> >
> > On Fri, Feb 12, 2021 at 5:51 PM Will Abramson <wip.abramson@gmail.com>
> wrote:
> > An immediate difference is that ERC-721 or I believe any token on
> Ethereum is transferable. I can send it to you, you could sell it to
> someone else using a platform like OpenSea, etc.
> >
> > This is not obviously possible using the Indy stack today without some
> hack involving the issuer of the credential revoking and re-issuing it. I
> believe there is some work in Ursa around the crypto for transferrable
> credentials but not sure what status and priority this has.
> >
> > Also, the ERC-721 keeps track of tokens and token holder addresses
> available to anyone who queries the contract.
> >
> > They are a couple that come to mind,
> >
> > Will
> >
> > On Thu, Feb 11, 2021 at 11:05 PM Michael Herman (Trusted Digital Web) <
> mwherman@parallelspace.net> wrote:
> > I hope this isn’t stretching the favorable use of the CCG mailing list…
> >
> > When are Hyperledger Indy/Sovrin VCs better than Ethereum smart
> contracts for NFEs/NFTs (non-fungible entities/tokens)?
> >
> > It seems obvious but I don't have a detailed/worked out answer.  One
> project I'm associated with wants to use the ERC-721 Non-Fungible Token
> Standard on Ethereum but I believe VCs are a better route to take. Part of
> the desire to stay on Ethereum is there is quite a vibrant NFT community on
> Ethereum and lots of different EC-721 tokens.
> >
> > https://eips.ethereum.org/EIPS/eip-721
> >
> > What are the considerations/decision points/knock-offs?
> >
> > Best regards,
> > Michael Herman
> > Sovrin Foundation Self-Sovereignist
> >
> > Self-Sovereign Blockchain Architect
> > Trusted Digital Web
> > Hyperonomy Digital Identity Lab
> > Parallelspace Corporation
> >
> > <image001.jpg>
>
>
Received on Monday, 15 February 2021 01:22:55 UTC

This archive was generated by hypermail 2.4.0 : Monday, 15 February 2021 01:22:56 UTC