W3C home > Mailing lists > Public > public-credentials@w3.org > June 2021

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

From: Adrian Gropper <agropper@healthurl.com>
Date: Thu, 24 Jun 2021 12:50:05 -0400
Message-ID: <CANYRo8jh9Xg+CkGT5+Sp_9AsQqp68QN0NUBXocSuyk3ZFoJPPg@mail.gmail.com>
To: Kyle Den Hartog <kyle.denhartog@mattr.global>
Cc: David Chadwick <d.w.chadwick@verifiablecredentials.info>, "public-credentials@w3.org" <public-credentials@w3.org>
Indeed, to the distinction that Alan and Kyle are making.

The big difference, as I see it, is that claims tend to be confidential and
permissions need not be confidential so selective disclosure is less of an
issue. When a capability issued by a resource server is attenuated by an
authorization server and the delegated result is presented back to the
original resource server / issuer as verifier, there's nothing to hide from
the verifier except maybe the identity of some of the delegation
intermediaries that are none of the resource server's business.

The GNAP group has spent many months discussing the issue of encrypted
tokens that are opaque to the end-user and their client. The end-user can
request from the authorization server whatever it wants but in the end the
resource server will give it whatever the decrypted token says. If that
includes child pornography the end-user did not request, it will be up to
the auditors to sort it out.

Adrian

On Thu, Jun 24, 2021 at 12:39 PM Kyle Den Hartog
<kyle.denhartog@mattr.global> wrote:

> > 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/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> <alanhkarp@gmail.com>
> *Sent:* Wednesday, June 23, 2021 8:08 AM
> *To:* Kyle Den Hartog <kyle.denhartog@mattr.global>
> <kyle.denhartog@mattr.global>
> *Cc:* Manu Sporny <msporny@digitalbazaar.com> <msporny@digitalbazaar.com>;
> W3C Credentials CG <public-credentials@w3.org> <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> <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> <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/
>
>
>
>
Received on Thursday, 24 June 2021 16:50:45 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 June 2021 16:50:47 UTC