Re: PROPOSALs for VC HTTP API call on 2021-06-22

Comments inline

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


On Tue, Jun 22, 2021 at 2:38 PM David Chadwick <
d.w.chadwick@verifiablecredentials.info> wrote:

>
> On 22/06/2021 21:08, Alan Karp wrote:
>
> If you don't allow delegation, people will share credentials, resulting in
> a system that is harder to use and less secure.
>
> Not every statement of "fact" in the above is always true. My wife and I
> do share our credit cards and PINs in order to withdraw cash from ATMs, as
> delegation is not possible. But the system is not harder to use, nor less
> secure. I would argue it is easier to use than either of us having to go
> through some additional delegation mechanism prior to visiting the ATM,
> since the mode of use (without delegation) remains the same for both of us.
>
Not everyone shares credentials in every situation, but people certainly do
when it's the only way they can get their jobs done.  Ping Identity even
has a webinar on how to get your employees to stop doing it.  Another
example was HP.  One of the few firing offenses was sharing your login
password with another employee, but all managers shared their passwords
with their admins as the only practical way to get their work done.

In your ATM example, both you and your wife have a pre-existing
relationship with your bank account.  What if you wanted your babysitter to
run to the ATM on your behalf?  Without a way to create a short-lived or
revocable permission, your only choice will be to give her your card and
PIN.  Wouldn't you prefer to have given her an authorization to withdraw
$200?

> We are all aware that VCs can be shared, and ZKPs perhaps more easily than
> others by sharing the master secret. This is independent of whether the VC
> can be delegated or not, or attenuated or not. The verifier has to be aware
> of this possibility even if delegation and attenuation are supported. With
> ZCAPs I can still give my capability to someone-else if I cannot be
> bothered to delegate it. Proof of possession cannot simply be proof of
> possession of the private key since this can be shared, even when it is
> stored in hardware.
>
If your system does not make it easy to get or create a new token that
potentially has a subset of your permissions, people will share the
corresponding private key when that's the only option.  The result is
granting more than the needed permissions and a loss of auditability.  Of
course, that may happen even if you make delegation easy.

> So to me, the critical factor is "can this privilege (whether it is a VC,
> ZCAP or any other credential) legitimately be shared or not? Car keys can
> be. Driving licenses (for driving) cannot be.
>
I think it's important to distinguish between what I have been calling
claims tokens from permission tokens.  I believe the requirements are quite
different.  It's up to the verifier to determine if a claim token can be
delegated.  As you say, it doesn't make sense to allow you to delegate your
driver's license.  It's different with a permission token.  If you do not
allow delegation, you will get a system with worse security that is harder
to use.

> The question is therefore not whether we need delegation or attenuated
> delegation to get it right, but rather, can the privilege or permission
> that we are talking about legitimately be shared or not. If it can then we
> need delegation and if the privilege can be made more fine grained, then
> attenuated delegation is needed. But if the privilege cannot and must not
> be delegated, then we don't need it.
>
You are correct for claims tokens.

> Who determines if a privilege or permission can be delegated? Is it the
> issuer or the verifier?
>
> So,
>
> Q. can a subject legitimately request their VC be issued to a delegated
> holder? Ans. It depends on the VC and on the Issuer. Some can be, some
> cannot be.
>
> Q. Can an RP legitimately request a delegate to validate its VP? Ans. It
> depends on the RP (and not on the verifier).
>
> Thus it seems to me that delegation and attenuation must be optional
> features of both the issuer and verifier APIs, and be determined by the
> issuer and the RP respectively.
>
I agree completely for claims tokens but not for permission tokens.

> Kind regards
>
> David
>