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