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

On Wed, Jun 23, 2021 at 5:40 PM Kyle Den Hartog <kyle.denhartog@mattr.global>
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. Hence we ended up on the same conclusion.
>
> That has been my concern all along, but I believe the complexity is
manageable if we carefully define which fields of a VC must and must not be
used when creating a permission token.  Basically, we end up with two
different specifications that share a common boilerplate.  If I understand
him correctly, Orie Steele's point is that there's a lot of VC code around
encryption and namespaces that can be reused if VCs can be used as
authorization tokens.  He believes it would be a shame to have to support a
completely different set of standards for claims tokens and permission
tokens.  I am sympathetic, but perhaps more worried about adverse
consequences than he is.  It sounds like you are in my camp on this point.


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

A big concern of mine.

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

I think it's important to be clear if the VC is making claims, e.g., this
person has been vaccinated, versus authorizing actions, e.g., this token
authorizes a particular action on a specific resource.

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

I agree.

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


On Wed, Jun 23, 2021 at 5:40 PM Kyle Den Hartog <kyle.denhartog@mattr.global>
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. 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
> <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/
>
>
>
>