How do we support delegation and attenuation of rights?

[David-Chadwick]

How do we show in the data model that the holder is not the subject of the credential, but has been delegated authority by the subject the right to present the claim to the inspector.

[msporny]

This is related to the object capabilities discussion we're having in the DID specification: w3c-ccg/did-spec#11

We will certainly want the same sort of feature set here. /cc @erights @cwebber

[David-Chadwick]

This topic is related to Subject NE Holder. So I suggest we close this issue and move the discussion to the new issue that I have opened on Subject NE Holder

[msporny]

More work happening here on delegation/attenuation: https://w3c-ccg.github.io/ld-ocap/

[David-Chadwick]

I believe that the work on capabilities is not really needed, because it is possible to define all capabilities as verifiable credentials. Here is an example taken from the id-ocap document

"id": "https://whatacar.example/a-fancy-car/proc/7a397d7b",
   "type": "Capability",
   "invocationTarget": "https://whatacar.example/a-fancy-car",
   "invoker": "https://social.example/alyssa/#key-for-car",
   "proof": {...}

this can be reformatted as the following VC

"id": "http://dmv.example.gov/credentials/3732",
  "type": ["Credential", "DriveACarCapability"],
  "issuer": "<the car's key ID>",
  "issued": "2010-01-01T19:73:24Z",
  "claim": {
    "id": "https://social.example/alyssa/#key-for-car",
    "invocationTarget": "https://whatacar.example/a-fancy-car",
  },
  "proof": { ... }

[cwebber]

It would be good if we could find that VC and ld-ocap can overlap more clearly and thanks @David-Chadwick for exploring this. I think this is a good attempt, so in the interest of figuring out if we can bring things closer together, let's try to poke at the differences so we can understand what they are:

• First of all is a difference of frame of mind. VCs typically talk "about" an entity that the target checks, and capabilities are something the invoker "holds on to". One reason we want to avoid looking at the invoker too much as "the type of entity that can do this" is we want to avoid "confused deputy" problems (which may be better explained as "role confusion attacks"). I do worry that by merging the two systems, implementors may accidentally look at "aspects about the invoker" every time and we'll accidentally open up implementations in practice to an attack. But maybe there is a way to get around that with careful narrative.
• Instead of a single type for Capability, we have DriveACarCapability. One reason this may be a concern is that I think we always want to know that a capability is a capability, and we're maybe mixing up the action of the target with the fact that it's a capability. I would instead suggest {"type": ["Credential", "Capability"], "claim": {..., "action": "DriveACar"}}. That said, I'm not really a fan of composite types when they can be avoided because I think all but the most powerful of graph-reasoning programmer brains do a bad job of working with them.
• There a lot of details of verifiable claims that involve reasoning about entity that I think just don't apply to capabilities. This may mean more for implementors to wade through.
• We haven't talked about invocation of a "VC" capability yet. What does an invocation look like? ld-ocap has a specific set of steps for verifying an invocation which involve walking up a chain. How do we reason about doing that in verifiable claims?
• How do we do the delegation and attenuation "chain" at all in verifiable claims? In ld-ocap this is absolutely core to the design. I'm not sure where we'd point "up the chain" in verifiable claims. I think we'd need to model the more complex examples of alyssa delegating-with-caveats to ben, and then ben delegating-with-caveats to Lem. Maybe we can do this... but adding a chain approach seems like a very late addition to VC.
• We're also hampered by the fact that we aren't allowed to specify a signature proof method in VC. In ld-ocap this is a core component; we sign/prove every document in a specific way and invocations are recognizable by having a specific type of signature/proof (with proofPurpose of invokeCapability and a capability object which points at the capability chain). I'm worried that because VC isn't "allowed" to have a specific proof mechanism that this would hamper that design.

So I'm all for exploring how to do it, but in short:

a) I'm worried that by mixing correlation and causation that we'll end up with confused deputies / role confusion
b) I'm worried that ld-ocap is currently a fairly clean and self-contained document, and layering on top of Verifiable Credentials will mean telling implementors "we're built on VC but ignore all these parts"
c) We need to figure out how to do document chains in VC
d) We need to model an invocation
e) We might need to commit to a signature/proof mechanism

[David-Chadwick]

Standards have the concept of Profiles, which are documents that limit the options that a base standard allows. Consequently we could specify a Capability Profile of Verifiable Credentials. The profile would allow you to
a) specify a single signature mechanism
b) say which parts of VCs should be ignored and do not apply to capabilities

Wrt to chains, this is a core requirement of VCs, as some VCs may need to refer to other VCs, and verifiable profiles need to refer to VCs. Consequently the VC spec is going to have to address this issue and document how it is solved. So I think this concern of yours will be addressed by the final VC spec.

[cwebber]

We have two issues here:

• Should linked data capabilities be modeled on verifiable credentials?
• How/should we delegate/attenuate terms of use? (Doing so may be totally useful even regardless of terms of use, because terms of use in verifiable credentials may be about policy)

[cwebber]

How/should we delegate/attenuate terms of use? (Doing so may be totally useful even regardless of terms of use, because terms of use in verifiable credentials may be about policy)

• Terms of use is going to invoke a human but not a machine process
• If terms of use is a human process, then we can't test for it normatively in the test suite
• Can attenuation even be possible for such a human process? Can you always grab the inner signed object and ignore the outer attenuated object?

Should linked data capabilities be modeled on verifiable credentials?

• Certainly ld-ocap could be built on VC, the question is whether it's a good idea
• Various developers think this will accidentally result in an ACL system, including the lead developer of linked data capabilities, which should be a useful data point.
• This is happening in the CCG anyway so we can figure it out there.

[cwebber]

I will write a PR for text to go into the spec with regard to the issue considering the above.

[burnburn]

Good discussion happening in PR #229.

[burnburn]

From TPAC 2018: This is not an authorization framework. See #252 and #204. Closing.