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

>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. Hence we ended up on the same conclusion.

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>
Sent: Wednesday, June 23, 2021 8:08 AM
To: Kyle Den Hartog <kyle.denhartog@mattr.global>
Cc: Manu Sporny <msporny@digitalbazaar.com>; W3C Credentials CG <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> 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> 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/