-
Notifications
You must be signed in to change notification settings - Fork 22
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
Milestone
Comments
This PR implements the second delegation described above (I think?), but using can=./update in addition to the can=*. |
This is blocked on storacha/ucanto#227 which has merged last night, but I do need to make a release |
Closed
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
When user issues
access/authorize
with some agent it should send invocation like shown below which in English translates to: "Agentdid:key:z6Mkk89bC3JrVqKie71YEcc5M1SMVxuCgNx6zLZ8SYJsxALi
is requesting all of the capabilities (can: *
) to be delegated to it bydid:mailto:web.mail:alice
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 todid:key:z6Mkk89bC3JrVqKie71YEcc5M1SMVxuCgNx6zLZ8SYJsxALi
(probably throughaccess/delegate
invocation)did:mailto:web.mail:alice
todid:key:z6Mkk89bC3JrVqKie71YEcc5M1SMVxuCgNx6zLZ8SYJsxALi
that is signed a special signature type (that is basically not signed).did:web:web3.storage
todid: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.All of the above implies that after user successfully completed
access/authorize
withdid:key:z6Mkk89bC3JrVqKie71YEcc5M1SMVxuCgNx6zLZ8SYJsxALi
agent, it can invokeaccess/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 thedid: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.
The text was updated successfully, but these errors were encountered: