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

> the complexity comes not from whether it is a claim or a permission, but from whether it is delegatable or not.

Agreed, when it comes to the number of checks that occur it's much greater because of the delegation. With that in mind, looking at the semantics only of the system VCs in my opinion weren't optimally designed for permission tokens. This difference between the two requires that an implementation that wants to support both claims tokens and permissions tokens has to grapple with the different mental model that arise when trying to stuff these things together. This introduces additional complexity. Additionally it leads to weird statements that are being made where it's difficult to tell if the VC is behaving like a claims token or a permissions token.

> Delegation is massively complex as I know from our X.509 AC PERMIS implementation. So whether the token is encoded as a VC, an X.509 AC or anything else is simply a question of syntax and parsing. Since we already have use cases of delegation in VCs (e.g. prescription handling) then I see no value in duplicating the effort in two different W3C specifications.

The value comes in being to separate the claims token from the permission tokens and by doing so we simplify the system. See this blog post that highlights the concerns I see with using VCs in authorization systems: https://kyledenhartog.com/example-authz-with-VCs/


[https://kyledenhartog.com/assets/img/profile.jpg]<https://kyledenhartog.com/example-authz-with-VCs/>
Example Design of an Authorization System with Verifiable Credentials and the Tradeoffs<https://kyledenhartog.com/example-authz-with-VCs/>
I’ll cover an example design which relies upon verifiable credentials for an authorization system and the tradeoffs faced.
kyledenhartog.com





> My point is, we cannot remove complexity from VCs and say they should only ever be used for subject EQ holder with no delegation of authority.

I do believe we can remove complexity by approaching problem differently. I don't believe that VCs are well designed to be used as permissions tokens personally, but I won't stop anyone who believes they are correct for their needs. In my case, I've yet to find a use case where VCs are better suited. With that said I think VCs are excellent at being claims tokens though. I'll follow up with a second blog post about how I think ZCAPs can be used to simplify the tradeoffs introduced in the post linked above.

-Kyle

________________________________
From: David Chadwick <d.w.chadwick@verifiablecredentials.info>
Sent: Thursday, June 24, 2021 8:57 PM
To: public-credentials@w3.org <public-credentials@w3.org>
Subject: Re: PROPOSALs for VC HTTP API call on 2021-06-22


And then we have to throw into the mix Power of Attorney, or Guardianship, of VCs where the holder is not the subject but still wants to present the Covid certificate on behalf of the donor to allow them to  enter the flight.....


My point is, we cannot remove complexity from VCs and say they should only ever be used for subject EQ holder with no delegation of authority.


Kind regards

David



On 24/06/2021 01:40, Kyle Den Hartog wrote:
>Authorizations are typically expressed as permissions allowed on a specific resource.  Your example is expressed as permission to speak for someone else about a specific claim.  These two views are similar but not identical.

Yup this is where I was going with the idea that the "semantics get messy, when you use VCs for authorization systems". Effectively the primary permission enabled by VCs is "I can assert who says what about me/what I say about about others)". While it's possible to bend VCs in a way that allows them to do more, it's likely going to result in a system that behaves in incompatible way to generalized software written to issue/hold/verify VCs. Alternatively, it's possible that the statements don't make sense as claims tokens are converted into permissions tokens.

The main reason I wanted to bring this up is to say, where you're going with your proposal is the right way. Even with it though, people can still bend around it in weird ways we probably don't want to allow still.

As an example, vaccination passes are often intended to be bound to a single holder (the subject of the vax pass). And per usual, the most common way they're being used is to authorize access to places/flights effectively building an authorization system with DIDs and VCs. With that in mind, are verifiers making sure DID and VC based delegation is being disabled to limit this capability since they explicitly don't want to allow delegation/ attenuated delegation with this use case? I'd highly suspect most systems aren't performing these checks and are going to be introducing some interesting vulnerabilities because of it.

So, in total I don't think we can blanket statement about these things (nor do I think we can test for them most of the time). So instead, we should be looking to spread the word on the right way to handle these design choices and make sure they get noted within the specs that are being drawn up by the community. One of which is by way of raising the proposal you did, which is a great starting point. Another of which is by continuing these discussions on forums like this mailing list.

-Kyle
________________________________
From: Alan Karp <alanhkarp@gmail.com><mailto:alanhkarp@gmail.com>
Sent: Wednesday, June 23, 2021 8:08 AM
To: Kyle Den Hartog <kyle.denhartog@mattr.global><mailto:kyle.denhartog@mattr.global>
Cc: Manu Sporny <msporny@digitalbazaar.com><mailto:msporny@digitalbazaar.com>; W3C Credentials CG <public-credentials@w3.org><mailto:public-credentials@w3.org>
Subject: Re: PROPOSALs for VC HTTP API call on 2021-06-22

On Mon, Jun 21, 2021 at 5:24 PM Kyle Den Hartog <kyle.denhartog@mattr.global><mailto:kyle.denhartog@mattr.global> wrote:
Just to clarify is it that we need delegation or attenuated delegation in order to get this right?

If you don't allow delegation, people will share credentials, resulting in a system that is harder to use and less secure.  If you can't attenuate when you delegate, then you can't enforce the Principle of Least Privilege.

Your examples are interesting.  Authorizations are typically expressed as permissions allowed on a specific resource.  Your example is expressed as permission to speak for someone else about a specific claim.  These two views are similar but not identical.  In the former, you know the verifier is the resource or an agent that it trusts; in the latter, the verifier is unknown when the certificate is created.  This difference has important implications for audit and revocation.

I agree with your conclusion unless the spec includes attenuated delegation of permissions.  I am less concerned about your examples, but that's probably because I'm not as familiar with that use case.

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


On Mon, Jun 21, 2021 at 5:24 PM Kyle Den Hartog <kyle.denhartog@mattr.global><mailto:kyle.denhartog@mattr.global> wrote:
Just to clarify is it that we need delegation or attenuated delegation in order to get this right?

While I agree with the sentiment that VCs shouldn't be used for authorization systems (because there's simpler, safer methods of building them), I wanted to add that there is ways to support delegation and attenuated delegation while keeping with using only DIDs and VCs. I wrote up a short github gist on the topic to cover the different ways in which I could see this being possible here: https://gist.github.com/kdenhartog/fa23c0da70933f5789b79cf916e4877b

[X]<https://gist.github.com/kdenhartog/fa23c0da70933f5789b79cf916e4877b>
Common delegation patterns in VC ecosystem<https://gist.github.com/kdenhartog/fa23c0da70933f5789b79cf916e4877b>
Common delegation patterns in VC ecosystem. GitHub Gist: instantly share code, notes, and snippets.
gist.github.com<http://gist.github.com>


The key thing to note is that while this is possible to do using DIDs and VCs, it's definitely not the simplest method (which often means vulnerabilities will be introduced in the authorization system) for achieving this and the semantics of the data become very weird.

For these reasons, I think it would actually be better to leave it at "verified credentials MUST NOT be used as authorizations to enable an authorization system".

-Kyle
________________________________
From: Alan Karp <alanhkarp@gmail.com<mailto:alanhkarp@gmail.com>>
Sent: Tuesday, June 22, 2021 8:47 AM
To: Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>>
Cc: W3C Credentials CG <public-credentials@w3.org<mailto:public-credentials@w3.org>>
Subject: Re: PROPOSALs for VC HTTP API call on 2021-06-22


I asked a number of people expert in capability systems if delegation is necessary to have a viable system.  They concluded it was unless every holder of an authorization token proxies every request in lieu of delegating.  I don't know how viable proxying is in the VC use cases.

Given that information, I would like to see an option specifying that verified credentials MUST NOT be used as authorizations unless they support attenuated delegation (I believe the OAuth term is sub-scope re-delegation.) and that any such system SHOULD support revocation.

If you don't support delegation, people will be forced to share access tokens.  The result will be loss of an audit trail and the likelihood that they will share more permissions than necessary.  The result is a less secure system that is harder to use.

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


On Mon, Jun 21, 2021 at 12:52 PM Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>> wrote:
Hi all, Here are some of the proposals that we didn't get to on the call last
week. We'll be processing them this week (these are all proposals that have
been circulated on the mailing list, I'm just summarizing them here):

PROPOSAL: Implementations SHOULD support authorization delegation by using
technologies such as GNAP and Authorization Capabilities.

PROPOSAL: Implementations MUST support authorization delegation by using
technologies such as GNAP and Authorization Capabilities.

PROPOSAL: Implementations are informally urged to support authorization
delegation. Implementations MAY support other authorization mechanisms,
especially ones that support authorization delegation.

PROPOSAL: Implementations MUST support OAuth2 for the /credentials/verify
endpoint. Implementations MAY support other authorization mechanisms for the
/credentials/verify endpoint.

We will be running these proposals tomorrow to come to some decisions wrt. the
direction of the authorization aspect of the work... after we process a few
PRs and issues.

-- 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/