- From: Matt Stone <mstone@stonecover.com>
- Date: Wed, 31 Oct 2018 11:06:25 -0600
- To: "public-vc-wg@w3.org" <public-vc-wg@w3.org>
- Message-ID: <CAJFiK0Y-nBX7Pp8Njqw=g_z8PM0JUiEFT+CK=NVo33LGSic2rA@mail.gmail.com>
I’m trying to synthesize all of the nuance I've gleaned from discussions about terms of use over the last couple of months. One observation is that we are conflating a couple of ideas when we say “Terms of Use”. There are some ToU that are expressed by the issuer when the credential is issued and there are some ToU that are expressed by the holder when the credential is presented to a verifier. To that end, I propose we differentiate these as “Issuer Terms of Use” and “Holder Terms of Use” Here are some characteristics that my be true about each. - Issuer Terms of Use - Market centric and generally re-usable. In other words, a credential like a college transcript or a passport will have approximately the same TOU regardless of the recipient of the issued credential. - These different policies will be very small in number relative to the holder population and as such may not need to “travel” with the credential, as long as it’s available by some mechanism (like on the ledger, or in the @context) - If they are included in the issued credential, they run the risk of being “left out”, i.e. not disclosed, in a selective disclosure scenario and thus may need to be reference differently in the credential definition. - Approach: Issuer Terms Of Use go in the in a central l location like @context or in the template on the ledger (sovrin example) - Holder Terms of Use - Very specific to the nature of the transaction for the specific presentation - Holders may want to express expectations and limits on the verifier or “delegate", when a holder is permitting another holder to present the credential on their behalf - see focal use case about citizenship where a parent's credential is bundled along with personal credentials in a single presentation. The “parent” allowed the “child” to use their credential “this” way for “this” transaction — I don’t know how we express this in a machine readable way, and it’s not our charter. - May only be relevant in non-ZKP scenarios where the verifier is getting a presentation with a collection of clear attributes and/or more personally identifiable information. - Approach: Holder Terms of Use go in the presentation and get signed along with the claims that are in the credential. I’m trying to break the logjam — does this help? If so, let's get the discussion into an issue and PR(s). -stone -- -stone
Received on Wednesday, 31 October 2018 17:06:59 UTC