Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Succesfull access/authorize should delegate capabilities to the agent so it can claim them #457

Closed
Gozala opened this issue Feb 27, 2023 · 3 comments · Fixed by #463
Closed
Assignees
Milestone

Comments

@Gozala
Copy link
Contributor

Gozala commented Feb 27, 2023

When user issues access/authorize with some agent it should send invocation like shown below which in English translates to: "Agent did:key:z6Mkk89bC3JrVqKie71YEcc5M1SMVxuCgNx6zLZ8SYJsxALi is requesting all of the capabilities (can: *) to be delegated to it by did:mailto:web.mail:alice

{
  "v": "0.9.1",
  "iss": "did:key:z6Mkk89bC3JrVqKie71YEcc5M1SMVxuCgNx6zLZ8SYJsxALi",
  "aud": "did:web:web3.storage",
  "att": [
    {
      "with": "did:key:z6Mkk89bC3JrVqKie71YEcc5M1SMVxuCgNx6zLZ8SYJsxALi",
      "can": "access/authorize",
      "nb": {
        "iss": "did:mailto:web.mail:alice",
        "att": [{"can":"*"}]
       }
    }
  ],
  "prf": [],
  "exp": 1685602800,
  "s": {
    "/": {
      "bytes": "7aEDQJbJqmyMxTxcK05XQKWfvxG+Tv+LWCJeE18RSMnciCZ/RQ21U75LA0uFSvIjdqnF5RaauZTE8mh2ZYMBBejdJQ4"
    }
  }
}

Capability provider is expected to perform interactive authorization with an email holder using email flow. If and when user grants requested capabilities access/authorize provider is expected to delegate two capabilities to did:key:z6Mkk89bC3JrVqKie71YEcc5M1SMVxuCgNx6zLZ8SYJsxALi (probably through access/delegate invocation)

  1. Delegation from did:mailto:web.mail:alice to did:key:z6Mkk89bC3JrVqKie71YEcc5M1SMVxuCgNx6zLZ8SYJsxALi that is signed a special signature type (that is basically not signed).
{
  "v": "0.9.1",
  "iss": "did:mailto:web.mail:alice",
  "aud": "did:key:z6Mkk89bC3JrVqKie71YEcc5M1SMVxuCgNx6zLZ8SYJsxALi",
  "att": [
    {
        "with": "ucan:*",
        "can": "*"
    }
  ],
  "prf": [],
  "exp": null,
  "s": {
    "/": {
      "bytes": "gKADAA"
    }
  }
}
  1. Delegation from did:web:web3.storage to did:key:z6Mkk89bC3JrVqKie71YEcc5M1SMVxuCgNx6zLZ8SYJsxALi that attests to the fact that first delegation ☝️ had been checked to be authorized by the user. This is attestation from us telling that hey don't check signature on the first one because we did checked it to be authorized.
{
  "v": "0.9.1",
  "iss": "did:web:web3.storage",
  "aud": "did:key:z6Mkk89bC3JrVqKie71YEcc5M1SMVxuCgNx6zLZ8SYJsxALi",
  "att": [
    {
      "with": "did:web:web3.storage",
      "can": "ucan/attest",
      "nb": {
          "proof": { "/": "bafy...above-delegation" }
       }
    }
  ],
  "prf": [],
  "exp": null,
  "s": {
    "/": {
      "bytes": "7aEDQJbJqmyMxTxcK05XQKWfvxG+Tv+LWCJeE18RSMnciCZ/RQ21U75LA0uFSvIjdqnF5RaauZTE8mh2ZYMBBejdJQ4"
    }
  }
}

All of the above implies that after user successfully completed access/authorize with did:key:z6Mkk89bC3JrVqKie71YEcc5M1SMVxuCgNx6zLZ8SYJsxALi agent, it can invoke access/claim from that agent and receive above two delegations because those were both delegated to it.

It also means that now did:key:z6Mkk89bC3JrVqKie71YEcc5M1SMVxuCgNx6zLZ8SYJsxALi can use above two delegations in the invocation proofs to do all the things that had been delegated to the did:mailto:web.mail:alice.

However there is one last piece to this puzzle, delegation from space did to account did must exist. Today we won't have such delegations because our clients have not been making them.

@gobengo
Copy link
Contributor

gobengo commented Feb 28, 2023

This PR implements the second delegation described above (I think?), but using can=./update in addition to the can=*.

@Gozala
Copy link
Contributor Author

Gozala commented Feb 28, 2023

This is blocked on storacha/ucanto#227 which has merged last night, but I do need to make a release

@Gozala Gozala added this to the w3up phase 3 milestone Feb 28, 2023
@Gozala Gozala self-assigned this Feb 28, 2023
@Gozala Gozala mentioned this issue Feb 28, 2023
@Gozala
Copy link
Contributor Author

Gozala commented Feb 28, 2023

This requires spec changes storacha/specs#50 which are awaiting reviews

gobengo added a commit that referenced this issue Feb 28, 2023
…on back to the issuer did:key so that access/claim works (#460)

Motivation:
* #455 
* This implements the second delegation described in
#457
* make this test pass once we deploy this to staging
gobengo/w3protocol-test#6

Test Case:
*
https://github.com/gobengo/w3protocol-test/pull/6/files#diff-698e92d7467a4a470689d4cb120272c6cac28864d4960ac12a3720ab7c35a15cR364

---------

Co-authored-by: Irakli Gozalishvili <contact@gozala.io>
gobengo added a commit that referenced this issue Apr 11, 2023
…on back to the issuer did:key so that access/claim works (#460)

Motivation:
* #455 
* This implements the second delegation described in
#457
* make this test pass once we deploy this to staging
gobengo/w3protocol-test#6

Test Case:
*
https://github.com/gobengo/w3protocol-test/pull/6/files#diff-698e92d7467a4a470689d4cb120272c6cac28864d4960ac12a3720ab7c35a15cR364

---------

Co-authored-by: Irakli Gozalishvili <contact@gozala.io>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants