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

Dear Adrian,
This is a super interesting use case. I am wondering if the following approach is towards the correct direction
The NFT has two fields: the "owner" and the "approved" user. The "owner" manages the NFT and the "approved" user can consume the NFT. Eventually, the NFT should end up having in the "approved" field the jti of the JWK that the AS generated. 

- The doctor as RO creates the NFT. It sets as "owner" the AS and it leaves the "approved" field empty
- The RQ  presents their credentials to the AS, the AS generates the JWT, the AS makes the "owner" of the NFT the RS (or the auditor) and leaves the "approved" field empty. The JWT cannot be used at this point.
- The RS (or the auditor) evaluates the RQ request and if it is valid it sets the "approved" field of the NFT equal to the jti of the JWT that the AS generated in the previous step.
- Now the RC can use the JWT.

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 15 Feb 2021, at 3:22 AM, Adrian Gropper <agropper@healthurl.com> wrote:
> 
> 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). 
>  • 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.) 
>  • The encryption key is shared with the patient who obviously can know what the prescription says.
>  • The encrypted prescription is stored with an RS anywhere the patient wants (patient wallet, EDV, personal data store, hospital IT system) 
>  • The patient chooses a pharmacy and a pharmacist (RQ) and shares the prescription URI (RS), the AS URL, and the encryption key.
>  • The RQ presents their credentials to the AS and receives a JWT for access to the RS.
>  • The RQ passes these to the pharmacy system (RC) and dispenses the medication.
>  • 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>
> 
> _._,_._,_
> Links:
> You receive all messages sent to this group.
> 
> View/Reply Online (#73) | Reply To Group | Reply To Sender | Mute This Topic | New Topic
> Your Subscription | Contact Group Owner | Unsubscribe [Fotiou@aueb.gr]
> 
> _._,_._,_