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

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

> As I understand confused deputy, the deputy is not only using the
> credential passed to it, but also its own credentials as well, to do
> whatever was requested of it.
>
The essence of the confused deputy is that the invoker designates the thing
to work on while the deputy uses its own permission for the access.  In the
canonical example, the deputy gets invoked with a string designating a file
to write.  The deputy then opens the file, which results in an open file
handle with write permission if the deputy has that permission even if the
invoker does not.  That's what comes from separating designation from
authorization.  Note that this attack would fail if the invoker had to
provide an open file handle, which does combine designation and
authorization.

> So this situation could also happen with capabilities if the recipient
> uses its own capabilities as well as those passed to it, e.g. the deputy is
> asked to fill and sign a check. The deputy has the capability to fill the
> check, and is passed the signing capability.
>
That's not a confused deputy.  By passing in the signing capability, the
invoker is proving it has permission to sign.  This example illustrates how
capabilities handle a very important situation.  Neither party can create a
signed check without help from the other one.  The check gets filled in and
signed only by collaborating in the way you describe.

> 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.
>
> And that is the advantage of them. The issuer does not need to know what
> resource it will be used for when the diploma is issued (e.g. apply for a
> job, apply for a higher degree, get promotion at work etc.). This is very
> similar to the RBAC model where one entity issues the role and another
> allows access to resources for certain role holders.
>
I completely agree that this is an important use case.

> Capabilities have their place when their use is known beforehand e.g. key
> to a hotel room. But a W3C VC can be issued that is restricted to do just
> that. Its just a question of defining the schema for the VC.
>
> That separation of designation from authorization is dangerous
>
> is advantageous I would say because of the added flexibility that is
> bestowed when it is needed (e.g. like a driving license).
>
I agree when the VC is being used as a credential, but it's a danger when
the VC is used as an authorization.

> and why I recommend keeping the two kinds of certificates distinct.
>
> You can do that with the W3C VC data model - it just needs us to define
> the properties for this
>
I completely agree.  It's just that some fields are required for one and
not the other.  Other fields mean one thing when defining a credential and
something else when defining an authorization.  Specifying the type removes
an ambiguity.

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


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

>
> On 07/09/2022 16:26, Alan Karp wrote:
>
> 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.
>
> As I understand confused deputy, the deputy is not only using the
> credential passed to it, but also its own credentials as well, to do
> whatever was requested of it.
>
> So this situation could also happen with capabilities if the recipient
> uses its own capabilities as well as those passed to it, e.g. the deputy is
> asked to fill and sign a check. The deputy has the capability to fill the
> check, and is passed the signing capability.
>
> 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.
>
> And that is the advantage of them. The issuer does not need to know what
> resource it will be used for when the diploma is issued (e.g. apply for a
> job, apply for a higher degree, get promotion at work etc.). This is very
> similar to the RBAC model where one entity issues the role and another
> allows access to resources for certain role holders.
>
> Capabilities have their place when their use is known beforehand e.g. key
> to a hotel room. But a W3C VC can be issued that is restricted to do just
> that. Its just a question of defining the schema for the VC.
>
> That separation of designation from authorization is dangerous
>
> is advantageous I would say because of the added flexibility that is
> bestowed when it is needed (e.g. like a driving license).
>
>
> and why I recommend keeping the two kinds of certificates distinct.
>
> You can do that with the W3C VC data model - it just needs us to define
> the properties for this
>
> Kind regards
>
> David
>
>
> --------------
> 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>
>>>
>>