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

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
[https://github.githubassets.com/images/modules/gists/gist-og-image.png]<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


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>
Sent: Tuesday, June 22, 2021 8:47 AM
To: Manu Sporny <msporny@digitalbazaar.com>
Cc: W3C Credentials CG <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/