RE: Funded Deployments of Verifiable Credentials - framework for meta-credentials

>> appreciate a little summary like the one you gave for the rows in the table 

 

I didn’t want to flood the thread with too much detail. Here is a 4 page draft with definitions for all eight terms as well as example use cases that folks have come up with to test how well the matrix holds up.

https://docs.google.com/document/d/17TyewSObxUahPjtq7kq0TXKm8fjOjr6a83xNZqa2Xns/edit?usp=sharing

 

 

From: Steve Capell <steve.capell@gmail.com> 
Sent: Tuesday, September 6, 2022 6:28 PM
To: steve.e.magennis@gmail.com
Cc: Alan Karp <alanhkarp@gmail.com>; Orie Steele <orie@transmute.industries>; Deventer, M.O. (Oskar) van <oskar.vandeventer@tno.nl>; W3C Credentials CG <public-credentials@w3.org>; Sporny, Manu <msporny@digitalbazaar.com>
Subject: Re: Funded Deployments of Verifiable Credentials - framework for meta-credentials

 

An interesting classification scheme.  We’ve been scratching our head a bit about how best to implement the last one (consumable entitlements) as we have several use cases for that pattern.  Initial thinking is that it should sit behind the status end point - your thoughts welcome 

 

Also, I think I know what you mean by the heading on the other axis (silo domain etc) but would really appreciate a little summary like the one you gave for the rows in the table 

 

Thanks !

Steven Capell

Mob: 0410 437854





On 7 Sep 2022, at 10:53 am, steve.e.magennis@gmail.com <mailto:steve.e.magennis@gmail.com>  wrote:



>> , I said that using VCs as capabilities would be viable if there was a required type that could be either "credential" or "authorization" in order to keep the use cases distinct.

 

 

FWIW, we’ve been discussing the notion of how credentials map to classes of use-cases, with a specific view to the implications associated with revocation. We landed on a 4x4 matrix that provides some good insight and seems to cover a lot of territory. Unfortunately I missed the conversations r.e. credential vs. capability, but would be very interested in reviewing the thinking if someone could point me to notes or recordings, etc. Would also appreciate any feedback on our thinking behind the below use case matrix for anyone interested. 

 

https://docs.google.com/document/d/17TyewSObxUahPjtq7kq0TXKm8fjOjr6a83xNZqa2Xns/edit?usp=sharing

 

Static Statement: Attestations that are, per the authority, inherently true and are not likely to change over time unless a significant problem is later found. For example: Lab test results, graduation diploma, biometric data for an individual, the VIN on an automobile.

 

Snapshot Statement: Attestations that are, per the authority, true at a specific point in time, but may well change in the future. For example: An automobile title, an address or phone number, a bank balance.

 

Expiring Entitlement: An entitlement that is assumed valid until a predetermined expiration date (a non- expiring entitlement can be thought of as having an expiration date really, really far in the future). Entitlements may be revoked for various reasons prior to expiring. For example: Drivers license, employment credential, safety certification, security access, passport

 

Consumable Entitlement: An entitlement for a fixed amount of something that is depleted (and potentially replenished) over time. For example: A medical prescription, a plane ticket, prepaid bank card, metro card. Sometimes an expiration date will be added to a credential with a consumable entitlement to limit the upper bound of its validity.

 

The second axis of the Use Case Matrix is concerned with the environment in which the credential type is to be used

 


 

Silo Domain

Partner Domain

No Affiliation

3rd Party Mandate


Static

Statement

 

   


Snapshot

Statement

 

 

  

Expiring Entitlements

    

Consumable Entitlements

   

 

 

 

From: Alan Karp <alanhkarp@gmail.com <mailto:alanhkarp@gmail.com> > 
Sent: Tuesday, September 6, 2022 4:22 PM
To: Orie Steele <orie@transmute.industries <mailto:orie@transmute.industries> >
Cc: Deventer, M.O. (Oskar) van <oskar.vandeventer@tno.nl <mailto:oskar.vandeventer@tno.nl> >; Capell, Steve <steve.capell@gmail.com <mailto:steve.capell@gmail.com> >; W3C Credentials CG <public-credentials@w3.org <mailto:public-credentials@w3.org> >; Sporny, Manu <msporny@digitalbazaar.com <mailto:msporny@digitalbazaar.com> >
Subject: Re: Funded Deployments of Verifiable Credentials - framework for meta-credentials

 

We discussed using VCs as capabilities a while back and concluded it was not a good idea.  The main reason is that the use cases are quite different.  You don't know ahead of time who will need to verify a credential; you do with a capability.  As a result, revocation is quite different for the two types.  Attenuated delegation is an important feature of capabilities, but its meaning is murky for credentials.  The argument for was the ability to use much of the same infrastructure for both.  At the time of that discussion, I said that using VCs as capabilities would be viable if there was a required type that could be either "credential" or "authorization" in order to keep the use cases distinct.

 

I looked at the examples on github.  Either I'm missing something basic (a distinct possibility), or what's there is unworkable in the real world.

 

--------------
Alan Karp

 

 

On Tue, Sep 6, 2022 at 6:29 AM Orie Steele <orie@transmute.industries <mailto:orie@transmute.industries> > wrote:

Related use case is NFTs that "allow you to participate in groups".

I've seen several versions of "authorization credentials", and we wrote a draft attempting to normalize them as related to capabilities.

https://github.com/transmute-industries/authorization-credentials

It's possible the next version of the vc data model could do more to define these "kinds" of credentials.

I suggest getting some framing together and maybe filing an issue?

OS




 

On Mon, Sep 5, 2022 at 5:44 AM Deventer, M.O. (Oskar) van <oskar.vandeventer@tno.nl <mailto:oskar.vandeventer@tno.nl> > wrote:

Hi Steve,

 

Please note that my email is broader than the subject of your question. The main use case is the meta-credentials for trusted issuers.

 

As for your question on verifier authorisation: enforcement is automated. 

* Compare with the fingerprint data in a European passport. Only authorized devices can verify European-passport fingerprints. The chip on a European passport simply blocks if an unauthorized device request to verify my fingerprints, even if an 800-pound gorilla <https://blockchain.tno.nl/blog/verify-the-verifier-anti-coercion-by-design/>  kindly asks me.
* Compare with my Dutch bank account. I can spend my wealth freely. However, even if I am held at gunpoint, my ATM machine gives me at most 5000€ per day.

This is the yin and yang of “self-sovereign”. Europe considers it important to protect its free citizens against 800-pound gorillas. This is why European eIDAS regulation requires accreditation of verifiers of sensitive government-issued credentials. If your EUDI-wallet implementation does not satisfy this requirement, then Europe won’t accredit it, and your customers cannot use it for government-issued credentials.

 

Best regards,

 

Oskar

 

 

From: Steve Capell <steve.capell@gmail.com <mailto:steve.capell@gmail.com> > 
Sent: maandag 5 september 2022 12:18
To: Deventer, M.O. (Oskar) van <oskar.vandeventer@tno.nl <mailto:oskar.vandeventer@tno.nl> >
Cc: W3C Credentials CG <public-credentials@w3.org <mailto:public-credentials@w3.org> >; Sporny, Manu <msporny@digitalbazaar.com <mailto:msporny@digitalbazaar.com> >
Subject: Re: Funded Deployments of Verifiable Credentials - framework for meta-credentials

 

How do you authorise a verifier?

 

Surely the whole point of a VC is that the holder owns the data and is free to choose who to present it it to.  So the act of presentation is the authority to verify.  

 

Who controls who can verify in this eIDAS requirement? Even if there was a use case where verification is authorised by some party, how would it be enforced?  If an issuer gives me a credential then I can present it to anyone I choose.  If there’s information I don’t want to disclose then I redact it.  All this is beyond the control of the issuer 

 

Steven Capell

Mob: 0410 437854

 

On 5 Sep 2022, at 8:05 pm, Deventer, M.O. (Oskar) van <oskar.vandeventer@tno.nl <mailto:oskar.vandeventer@tno.nl> > wrote:

 

Hi Manu, all,

 

Is there already ongoing work on “meta-credentials”, or should there be in W3C-CCG?

 

Verifiable credentials are always associated with some assurances.

1. The issuer is trusted to issue this type of credential (https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0289-toip-stack#discovery-and-verification-of-authoritative-issuers)
2. The verifier is authorized to verify this type of credential (https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0289-toip-stack#discovery-and-verification-of-authoritative-verifiers)

The former is the regular decision of a verifier to trust an issuer. The latter relates e.g. to the European eIDAS requirement that a verifier needs to be authorized to verify certain sensitive government-issued credentials.

 

Internet-reachable trust lists are the default solution to check whether an issuer or verifier is accredited to issue/verifier a certain type of credential, for example the EBSI Trusted Issuers Registry <https://ec.europa.eu/digital-building-blocks/wikis/display/EBSIDOC/Trusted+Issuers+Registry+API>  or other (Fraunhofer-TRAIN <https://essif-lab.eu/essif-train-by-fraunhofer-gesellschaft/> ). However, internet-reachable trust lists have some major disadvantages.

a. They don’t work in offline scenarios
b. The “phone-home” interaction leaks information (=privacy)

 

An obvious alternative is meta-credentials, i.e. credentials about being authorized to issue/verify a certain type of credential. This alternative had already been highlighted in the aforementioned TOIP RFC 0289 <https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0289-toip-stack#defining-a-governance-framework> . There are many credential types, and potentially equally many of these meta-credentials. Nevertheless, it may be useful to develop a framework that enables automated verification of meta-credentials. At least it should be automatically verifiable whether a presented meta-credential is applicable to the type of credential that is requested or presented. Perhaps W3C could develop a generic solution for this?

 

Any thoughts?

 

Best regards,

 

Oskar

 

 

-----Original Message-----
From: Manu Sporny < <mailto:msporny@digitalbazaar.com> msporny@digitalbazaar.com> 
Sent: zaterdag 27 augustus 2022 20:48
To: W3C Credentials CG < <mailto:public-credentials@w3.org> public-credentials@w3.org>
Subject: Funded Deployments of Verifiable Credentials

 

Hi everyone (VCWG BCC'd),

 

I've been asked to do a presentation around funded deployments of Verifiable Credentials at multiple upcoming conferences (W3C TPAC, RWoT, etc.) and don't feel like I have a firm grasp of every publicly funded Verifiable Credential deployment happening around the world.

 

If you are funded to pilot or productionize a system that uses DIDs or Verifiable Credentials, and you are comfortable with talking about the program publicly, please add details to this slide deck:

 

https://docs.google.com/presentation/d/1JjfDbeXfE7aO7uYDNqNQ8ixVr9tXUQL7mhwudwxZN38/edit

 

I know I'm missing publicly announced projects from MATTR, Mesur.io, Mavennet, Transmute, and possibly Avast, ESSIF, the German government, and others. If you know of someone that's not on these lists, but is deploying VCs and DIDs, please send this request to them.

 

The first presentation is in two weeks, so please add your projects into the deck before then.

 

-- manu

 

--

Manu Sporny -  <https://www.linkedin.com/in/manusporny/> https://www.linkedin.com/in/manusporny/

Founder/CEO - Digital Bazaar, Inc.

News: Digital Bazaar Announces New Case Studies (2021)  <https://www.digitalbazaar.com/> https://www.digitalbazaar.com/

 

 

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.




 

-- 

ORIE STEELE

Chief Technical Officer

www.transmute.industries <http://www.transmute.industries>