Re: Reusing VCs in a safe and meaningful way

I continue to argue against using VCs for both claims and permissions.  I
just posted my reasoning to
https://github.com/w3c/vc-data-model/issues/870#issuecomment-1712652704 and
copied the post below.

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

--------------------------------------
(A very long thread that I only read the end of, but I've participated in
such discussions before.)

While VCs are great for making claims, do not use them for granting
permissions. There are a number of issues.

Invocation: A permissions VC must designate a specific object that the
invocation request applies to, and the invocation may include delegation to
the invokee of permissions to parameters being passed. A claims VC
typically designates some entity, e.g., the person granted a driver's
license, and invocation makes no sense.

Delegation: You must support attenuated delegation chains for permissions.
Relatively few claims are delegatable. When they are, the mechanisms are
quite different, e.g., Alice acting as manager while Bob is on vacation vs.
Alice using some permissions that Bob explicitly delegated to her.

Revocation: You don't know who will be verifying a claims VC, but you do
know who will be verifying a permissions VC. As a result, the revocation
mechanisms are completely different.

As a result of these differences, there are certain fields that must appear
in a claims VC that make no sense in a permissions VC, and vice versa. You
are creating a lot of confusion for both creators and consumers of VCs if
you overload them this way.

That being said, you can reuse the VC infrastructure for both if there is a
field in the VC that denotes whether the credential is for a claim, e.g.,
driver's license, or a permission, e.g., authorization to read some object.
If you do, you'll need 2 intertwined specs given the subtleties of using
certificates for authorization. Perhaps you'd be better off using something
like zcap-ld <https://w3c-ccg.github.io/zcap-spec/> for authorizations.



On Thu, Sep 7, 2023 at 11:08 PM Alen Horvat <horvat.alen@yahoo.com> wrote:

> Hi.
>
> This essentially falls either under an accreditation model or delegated
> authorisation.
> Here are 2 sample data models:
> - Accreditation
> https://code.europa.eu/ebsi/json-schema/-/blob/main/schemas/ebsi-accreditation/2023-04/schema.json
>
> - delegated authorisation:
> https://code.europa.eu/ebsi/json-schema/-/blob/feat/ebsiint-7198/schemas/ebsi-authorisation/2023-09/schema.json
>
> In the case of authorisation, we are embedding the VC, that is a basis for
> the delegation, in the Evidence property.
>
> We’re using the following pattern:
> - if VC-A is about the issuer/signer -> put it in the signature as signed
> or unsigned element
> - if VC-A is about the content, we put it in the Evidence (can be embedded
> or referenced, depending on the use case needs)
>
> Related question:
> https://github.com/w3c/vc-data-model/issues/870#issuecomment-1705205519
>
> BR, Alen
>
> On 8 Sep 2023, at 04:44, ステファニー タン（SBIホールディングス） <tstefan@sbigroup.co.jp>
> wrote:
>
> Dear all,
>
> This is Stefannie again. First off, I would like to thank everyone who
> sent in their opinions, suggestions and follow-up questions with our
> previous question regarding DID method-specific-id. I passed it on to our
> engineering team and we are currently doing further investigation.
>
> I have another question from our engineering side, this time regarding how
> VCs can be reused in a safe and meaningful way.
>
> Please see below our Business design, Business Flow and Technical
> Solutions that we are considering.
>
> [Business Design]
> Companies should get a VC from a trust-worthy organization before they can
> transact with each other.
>
> [Business Flow]
> Here is the Business flow for the case when Company A needs to sell
> Product B to Company B,  and Product C to Company C.
>
>    1. Company A gets a VC (VC-A) from the trust-worthy organization.
>    2. Company A, in its internal system, makes TraceID-B for selling
>    Production B to Company B.
>    3. In the same way, Company A, in its internal system, makes TraceID-C
>    for selling Production C to Company C.
>    4. Company A needs to share Production B info(i.e. production name),
>    TraceID-B and the VC-A with Company B.
>    5. In the same way, Company A needs to share Production C info(i.e.
>    production name),  TraceID-C and the VC-A with Company C.
>
> [Technical Solution]
> To achieve the above, while keeping in line with DID VC protocol, we
> discussed two solutions.
>
>    1. Company A builds a new self-signed VC-B with Production B info and
>    TraceID-B.  Then, Company A makes VP-B by signing against VC-A and VC-B.
>    Finally, Company A passes VP-B to Company B for verification purposes.
>    2. Company A makes VP-B by signing against VC-A. Then,  Company A
>    builds a new self-signed VC-B with Production B info and TraceID-B and
>    VP-B.  Finally, Company A passes VC-B to Company B for verification
>    purposes.
>
>
> We are wondering which one of the two solutions fits more into the DIDVC
> protocol.  At the same time, we would like to know whether there are
> potentially other solutions.
>
> Best regards,
> Stefannie
> SBI Holdings, Inc.
>
>
>