Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Way to connect delegation chains #130

@Gozala

Description

@Gozala

Pulling piece of discussion from storacha/w3up#182 (comment) after realizing that did:dns has nothing to do with actual problem.

Ok so let's consider following scenario:

  1. User delegates some capability did:key:zAlice delegates to did:key:zW3 service.
  2. did:key:zW3 private key is not in any computer it's on piece of paper in safe deposit box.
  3. did:key:zW3 has a delegate did:key:zService which acts on it's behalf
  4. Service needs to redelegate capability received from did:key:zAlice, but it can not because delegation can not be signed by did:key:zService

In other words we have two delegation chains that if we were to connect we'd get a valid delegation chain. We could construct delegation like

{
  iss: "did:key:zService",
  aud: "did:key:zZzzz",
  exp: null,
  att: [{ with: "did:key:zAlice", can: "*" }],
  prf: [
    // did:key:zAlice -> did:key:zW3
    {
      iss: "did:key:zAlice",
      aud: "did:key:zW3",
      exp: null,
      att: [{ with: "did:key:zAlice", can: "*" }],
    },
    // did:key:zW3 -> did:key:zService
    {
      iss: "did:key:zW3",
      aud: "did:key:zService",
      exp: null,
      att: [{ with: "*", can: "*" }],
    },
  ],

However above delegation would not be valid because:

  1. We do not have with: * or a way to describe resources delegated to an issuer.
    • Perhaps ucan:* could be expanded to imply not only all proofs but also all siblings that delegate to the iss ?
    • Or we could make with: * be a thing ?
  2. It is violates principal alignment because aud in second proof is did:key:zW3 and not did:key:zService.
    • Perhaps spec should allow pushing misaligned proofs into a siblings with matching iss, because you are providing proof on their behalf. It would only work one level deep, but that seems ok.
    • Alternatively mismatched proofs could be moved into all the siblings, that way delegation several levels above could provide a proof on behalf of the issuer there.

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions