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

On Wed, Sep 7, 2022 at 1:35 AM David Chadwick <d.w.chadwick@truetrust.co.uk>
wrote:

> Depending upon your definition, every VC is an authorisation for
> something, otherwise there would be little point in having it.
>

A key feature of a capability is that it combines designation with
authorization.  Any time you separate those two things, you leave yourself
open to a confused deputy attack.  Your diploma does not designate a
resource and an authorization.  It is a statement about you that may be
used for a variety of purposes.  That separation of designation from
authorization is dangerous and why I recommend keeping the two kinds of
certificates distinct.

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


On Wed, Sep 7, 2022 at 1:35 AM David Chadwick <d.w.chadwick@truetrust.co.uk>
wrote:

>
> On 07/09/2022 00:22, Alan Karp wrote:
>
> We discussed using VCs as capabilities a while back and concluded it was
> not a good idea.
>
> Not everyone agreed this :-)
>
> 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.
>
> This has not stopped people using driving licenses to buy alcohol at a
> variety of outlets, or enter night clubs or do a whole variety of things
> that were not envisaged by the issuing authority.
>
>
> As a result, revocation is quite different for the two types.
>
> Which is why VCs tell the verifier what the verification method is.
>
>
>   Attenuated delegation is an important feature of capabilities, but its
> meaning is murky for credentials.
>
> I agree that delegation of VCs has not been standardised yet
>
>
> 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.
>
> Depending upon your definition, every VC is an authorisation for
> something, otherwise there would be little point in having it.
>
> Kind regards
>
> David
>
>
> 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>
> <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> 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>
>>> *Sent:* maandag 5 september 2022 12:18
>>> *To:* Deventer, M.O. (Oskar) van <oskar.vandeventer@tno.nl>
>>> *Cc:* W3C Credentials CG <public-credentials@w3.org>; Sporny, Manu <
>>> 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> 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.
>>>
>>>    1. They don’t work in offline scenarios
>>>    2. 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 <msporny@digitalbazaar.com>
>>> Sent: zaterdag 27 augustus 2022 20:48
>>> To: W3C Credentials CG <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/
>>>
>>> Founder/CEO - Digital Bazaar, Inc.
>>>
>>> News: Digital Bazaar Announces New Case Studies (2021)
>>> 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
>>
>> <https://www.transmute.industries>
>>
>