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> 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> 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>
> 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>
>> wrote:
>>
>>> What kind of NFTs are you building?
>>>
>>> - Adrian
>>>
>>> On Tue, Jun 8, 2021 at 6:30 PM Steve Capell <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>
>>>> 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
> Humanitarian Physicians Empowerment Community
> Humanitarian Physicians Empowerment Coin
>
>