Re: Identifiers in Verifiable Credentials

I can see the inevitable proliferation of NFISPSPAT viral memes now (move over #doge). Steve, you’re a marketing genius; don’t let anyone tell you otherwise :)

________________________________
From: steve.e.magennis@gmail.com <steve.e.magennis@gmail.com>
Sent: Thursday, June 10, 2021 7:44 PM
To: 'Adrian Gropper'; 'steve capell'
Cc: 'Leah Houston, MD'; 'Manu Sporny'; 'W3C Credentials Community Group'
Subject: RE: Identifiers in Verifiable Credentials

Our designers also called credentials NFT’s when we were working through the user journeys.
I said “well I guess you can call them NFNTT’s”
(non-fungible non-transferable tokens)

When an NFT (VC) is tethered to a subject (DID) isn’t that what it is?


Except when authority / agency needs to be delegated or usurped (e.g. custodial relationship) so maybe
NTISPSPAT
(non-fungible, immutable subject, potentially subject to powers of attorney tokens)
Rolls right off the tongue 😊

From: Adrian Gropper <agropper@healthurl.com>
Sent: Thursday, June 10, 2021 4:45 PM
To: steve capell <steve.capell@gmail.com>
Cc: Leah Houston, MD <leah@hpec.io>; Manu Sporny <msporny@digitalbazaar.com>; W3C Credentials Community Group <public-credentials@w3.org>
Subject: Re: Identifiers in Verifiable Credentials

Hi Steve,

Your perspective is valuable. I'd like to relate it to the subject of this thread: "Identifiers in Verifiable Credentials".

To your bullets:

  *   Are you talking about technical and semantic interoperability of the subject identifier in a VC? That might be Levels of Assurance in an identity or maybe methods for linking separate subject identifiers presented as part of multiple credentials. Or it could be methods the subject to prove control over a VC. All of this is very important in terms of privacy.  Should we  talk about this separately from the semantics of the claims in the credential or do these concerns always come together?
  *   Regulatory interoperability is indeed separable from technical and semantic. As above, are we able to separate regulations pertaining to identity vs. those that pertain to the claims about the identity.
It's useful to separate concerns because the interoperability of identity is never domain specific. What works for gov also works for education, and health, and commerce. For example, they all use our driver's license, social security number or email as a root identity.

On the other hand, regulatory interoperability is almost always domain specific.

It's early days for SSI standards and I see government digital identity projects eager to say that they are only aiming for uses in the public-sector while realizing full-well that what they do will impact other sectors. A good example is Aahaar.

Adrian

On Thu, Jun 10, 2021 at 6:24 PM steve capell <steve.capell@gmail.com<mailto:steve.capell@gmail.com>> wrote:
Hi Leah

I don’t have a platform to sell.  We just do consulting and fun experiments to test future operating models for federal government agencies.  The last thing we would want to build is another supply chain traceability platform.  What we are interested to test is:

  *   Can we drive technical and semantic interoperability standards and supporting test suites so that a VC issued from one platform can be verified by another.  I'm using "platform" in a very generic sense here - noting that some are hub centric and some are already somewhat decentralised.  US DHS is obviously helping a lot here by leading the plug-fests. So it's more the semantic domain that we are focussed on.  There will never be one authority or source of traceability or other semantics so we'll need to recognise several and develop semantic equivalence rules.
  *   Can we develop usable cross-domain assurance models (aka "reg-tech") that can allow a claim issued under one framework (regulatory or commercial) to be considered equivalent and re-usable to satisfy an assurance requirement of a different framework?  Currently our tools are jupyter notebooks and data science to analyse reams of text based rules. Hopefully the output of that will map to a standard assurance reference model (metamodel) that can be used to automate assurance assessments given a linked graph of VC claims.
cheers,
steve


Steven Capell
Mob: 0410 437854


On 10 Jun 2021, at 6:33 pm, Leah Houston, MD <leah@hpec.io<mailto:leah@hpec.io>> wrote:


Hey Steve,

Our designers also called credentials NFT’s when we were working through the user journeys.
I said “well I guess you can call them NFNTT’s”
(non-fungible non-transferable tokens)

When an NFT (VC) is tethered to a subject (DID) isn’t that what it is? I appreciate feedback from the rest of the group on this as well.

That being said steve-  I have people who have interest in doing this in the pharmaceutical supply chain that may be interested in your platform if you want to connect one to one.

Best
Leah


On Tue, Jun 8, 2021 at 11:57 PM steve capell <steve.capell@gmail.com<mailto:steve.capell@gmail.com>> wrote:
Hi Adrian,

We've got a few goals with all this:

  *   really short term (ie doing it now) - "simple VCs" to replace cross-border paper documents with verifiable credentials for improved integrity & efficiency.  Specific examples

     *   preferential and non-preferential certificates of origin
     *   Phytosanitary (food health/quality) certificates

  *   medium term (experimenting with it now) - "participation in the trust economy" to prove a model where regulators (eg department of agriculture) can leverage industry assurance schemes as  in order to reduce burden on trusted parties and to improve detection of non-compliance.  Specific examples:

     *   Developing a mutual recognition framework and supporting harmonised vocabulary of claims from multiple food safety assurance schemes (bit of machine learning in this) so that producers / exporters need only prove a thing once. eg a typical farmer in AU has to comply with https://www.foodauthority.nsw.gov.au/,   https://saiplatform.org/,  https://harpsonline.com.au/,   https://micor.agriculture.gov.au/Pages/default.aspx and more - if a farmer has verifiable compliance claims from a trusted industry assurance framework then the regulator will accept them
     *   Leveraging high integrity digital trade documents to reverse the regulatory compliance paradigm from (for example) "read that huge stack of rules and figure out your duty payment" to "give us your commercial invoice and we'll tell you what duty to pay".

  *   longer term (but not too far away) - supply chain transparency and traceability across/between multiple trust networks.  There's lots of "use my blockchain magic platform to get traceability in your supply chain" type products out there now.  All have a specific geography and industry niche.  None will become the "facebook of trade" (thankfully!) and, in most cases, even one consignment touches multiple platforms.  So genuine transparency and traceability needs cross-platform linked claims. That's where VCs excel. The interesting challenge here is is how to do that without explicit authority delegations between parties that dont know each other but rather do it via a (kind of) off-chain NFT that accompanies the goods in any leg of a value chain.  We're doing some fun experiments with that now.
kind regards,

On Wed, 9 Jun 2021 at 12:40, Adrian Gropper <agropper@healthurl.com<mailto:agropper@healthurl.com>> wrote:
What kind of NFTs are you building?

- Adrian

On Tue, Jun 8, 2021 at 6:30 PM Steve Capell <steve.capell@gmail.com<mailto:steve.capell@gmail.com>> wrote:
Isn’t it true that pretty much every VC that is about a “thing” (eg an invoice about a shipment , a bill of lading about a consignment, an origin certificate about a product , etc) are bearer VCs because the verifier only cares about proof of issuer ID.  the ID of the thing (subject) isn’t something that the thing has to (or is able to) prove.  It’s just an assertion by the issuer

These “esoteric” cases represent 99% of my use cases and volumes

Steven Capell
Mob: 0410 437854

> On 9 Jun 2021, at 6:02 am, Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>> wrote:
>
> On 6/6/21 5:57 PM, Kerri Lemoie wrote:
>> I’m not clear on the uses for the optional id in the vc assertion. It
>> would be helpful to learn about some examples or suggested uses.
>
> I saw answers for why you wouldn't want to use an `id` in the VC assertion. I
> didn't see many examples of why you would want to use `id`. Here are two:
>
> * You have a single-use bearer token (movie ticket, age
>  token) that you want to determine if it's been used
>  before or not. Identifiers like this are useful for that
>  use case:
>
>  urn:uuid:ddf810cc-c891-11eb-9fd3-67046f0b67f0
>
>  These sorts of identifiers also compress well when
>  using CBOR-LD (to 16 bytes) and help when encoding
>  to QR Codes.
>
> * You have a public Verifiable Credential where you
>  might want to publish other information, such as
>  an HTML representation of the VC. An Open Badge
>  URL might be a good use here.
>
> There are other uses, but they tend to be fairly use case specific and thus,
> esoteric.
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/

> Founder/CEO - Digital Bazaar, Inc.
> blog: Veres One Decentralized Identifier Blockchain Launches
> https://tinyurl.com/veres-one-launches

>
>


--
Steve Capell

--
Leah Houston M.D.
President and Founding Partner
www.hpec.io<http://www.hpec.io>
Humanitarian Physicians Empowerment Community
Humanitarian Physicians Empowerment Coin