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

feat: access/authorize confirmation email click results in a delegation back to the issuer did:key so that access/claim works #460

Conversation

…esult-in-space-being-registered-and-accessdelegate-for-space-allowed
@gobengo gobengo temporarily deployed to dev February 28, 2023 01:38 — with GitHub Actions Inactive
@gobengo gobengo changed the title space registration that allows access/delegate feat: access/authorize confirmation email click results in a delegation back to the issuer did:key so that access/claim works Feb 28, 2023
Copy link
Contributor

@Gozala Gozala left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's cool that more tests are added, but I'm afraid it's not going to do what you're aiming for.

// invocations invoked by the did:key
const delegateToKey = await ucanto.delegate({
issuer: env.signer,
audience: {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Audience of ./update capabilities is meant to be non did:key principal, because those are only times ucanto would look at ./update capabilities. Delegation to the agent key is not going to get you anything other than been able to claim that delegation from that agent afterwards.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok. I updated to not use ./update. If what I updated to is even remotely tolerable on staging, it would be real nice to merge it because any delegation in there with the correct audience will make the tests pass.

@gobengo gobengo temporarily deployed to dev February 28, 2023 07:10 — with GitHub Actions Inactive
@gobengo gobengo requested a review from Gozala February 28, 2023 07:11
@gobengo
Copy link
Contributor Author

gobengo commented Feb 28, 2023

@Gozala after your last review e.g. this comment, I updated this to have clicking the confirmation email generate a ucan/attest as described in #457 .

wdyt?

@gobengo gobengo temporarily deployed to dev February 28, 2023 08:54 — with GitHub Actions Inactive
@gobengo gobengo temporarily deployed to dev February 28, 2023 09:06 — with GitHub Actions Inactive
@gobengo gobengo temporarily deployed to dev February 28, 2023 09:35 — with GitHub Actions Inactive
Copy link
Contributor

@Gozala Gozala left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's trying to do both old auth and new auth together but mixes two in a weird way.


const agentPubkey = accessSessionResult.capability.nb.key

const update = await ucanto.delegate({
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would really help to add comment above explaining what this delegation intends to do. In the version that I think this implements this delegation is attestation from us that account has authorized agent key to be able to sign ucans where issuer is account did.

},
],
})
const attestKeyAuthorizesAccount = await ucanto.delegate({
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment here describing what it's meant to do would also help, because it does not do what spec or issue suggests and it's not clear to me what the intentions are.

with: env.signer.did(),
can: 'ucan/attest',
nb: {
proof: update.cid,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be the CID for the (unsigned) delegation from an account to the agent. This delegation should be replacement for the update above. More concretely if update was attesting to the authorization of the key, this attestation should be for the authorization of the specific delegation.

That is the core change in the spec, if previously we were attesting to key authorization which implied sudo privileges, in a new version we attest to the specific delegation authorization. Which means it could be sudo privileges or a very specific capabilities.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reading further down I think you could just remove this delegation.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

})

// create delegations that should be claimable
const delegationAccountToKey = await ucanto.delegate({
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is somewhat correct, except it will have a signature from accountOneOffKey key as opposed to having an "absent" signature. Which may be ok temporarily, but not in MVP because those could fail to validate.

// generate a delegation to the key that we can save in
// models.delegations to be found by subsequent access/claim
// invocations invoked by the did:key
const delegateToKey = await ucanto.delegate({
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably should be renamed and update comments as it does a different thing now.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

renamed/recommented in 685af65

return agentPubkey
},
},
proofs: [delegationAccountToKey],
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure what is this for ? This could either contain delegation from did:web:web3.storage to a service key, or if they are the same no proof is required.

})
await env.models.delegations.putMany(
delegateToKey,
attestKeyAuthorizesAccount
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you need to put delegationAccountToKey and delegateToKey instead.

assert.ok(expectAccountToKey, 'expect proofs to contain delegation')
assert.deepEqual(expectAccountToKey.issuer.did(), accountDID)
assert.deepEqual(expectAccountToKey.audience.did(), issuer.did())
assert.deepEqual(expectAccountToKey.capabilities, [
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove this whole delegation if it's not needed for this test

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done in 685af65

@gobengo gobengo temporarily deployed to dev February 28, 2023 19:14 — with GitHub Actions Inactive
@gobengo gobengo requested a review from Gozala February 28, 2023 19:20
@gobengo
Copy link
Contributor Author

gobengo commented Feb 28, 2023

I think it's trying to do both old auth and new auth together but mixes two in a weird way.

I removed the new

packages/access-api/src/routes/validate-email.js Outdated Show resolved Hide resolved
capabilities: [
{
with: env.signer.did(),
can: 'access-api/delegation',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
can: 'access-api/delegation',
can: 'access/delegation'

Nit: It just occurred to me that you can use access/delegate here as spec-ed except with audience being an agent as opposed to service.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm down to change to that post-merge but otherwise I'd prefer to make this a meaningless can

@gobengo gobengo temporarily deployed to dev February 28, 2023 21:22 — with GitHub Actions Inactive
@gobengo gobengo merged commit a466a7d into main Feb 28, 2023
@gobengo gobengo deleted the 458-successful-accessauthorize-flow-should-result-in-space-being-registered-and-accessdelegate-for-space-allowed branch February 28, 2023 21:24
@gobengo
Copy link
Contributor Author

gobengo commented Mar 1, 2023

when testing this on staging, I ran into an error due to #464

alanshaw pushed a commit that referenced this pull request Mar 23, 2023
🤖 I have created a release *beep* *boop*
---


##
[5.0.0](access-api-v4.11.0...access-api-v5.0.0)
(2023-03-23)


### ⚠ BREAKING CHANGES

* implement new account-based multi-device flow
([#433](#433))
* upgrade capabilities to latest ucanto
([#463](#463))

### Features

* access-api handles provider/add invocations
([#462](#462))
([5fb56f7](5fb56f7))
* access-api serves access/claim invocations
([#456](#456))
([baacf35](baacf35))
* access/authorize confirmation email click results in a delegation back
to the issuer did:key so that access/claim works
([#460](#460))
([a466a7d](a466a7d))
* allow multiple providers
([#595](#595))
([96c5a2e](96c5a2e))
* define `access/confirm` handler and use it in ucanto-test-utils
registerSpaces + validate-email handler
([#530](#530))
([b1bbc90](b1bbc90))
* handle access/delegate invocations without error
([#427](#427))
([4f0bd1c](4f0bd1c))
* if POST /validate-email?mode=authorize catches error w/ too big qr
code ([#516](#516))
([d0df525](d0df525))
* implement new account-based multi-device flow
([#433](#433))
([1ddc6a0](1ddc6a0))
* includes proofs chains in the delegated authorization chain
([#467](#467))
([5144293](5144293))
* move access-api delegation bytes out of d1 and into r2
([#578](#578))
([4510c9a](4510c9a))
* move validation flow to a Durable Object to make it ⏩ fast ⏩ fast ⏩
fast ⏩ ([#449](#449))
([02d7552](02d7552))
* provision provider type is now the DID of the w3s service
([#528](#528))
([6a72855](6a72855))
* space/info will not error for spaces that have had storage provider
added via provider/add
([#510](#510))
([ea4e872](ea4e872))
* upgrade capabilities to latest ucanto
([#463](#463))
([2d786ee](2d786ee))
* upgrade to new ucanto
([#498](#498))
([dcb41a9](dcb41a9))
* write invocations and receipts into ucan log
([#592](#592))
([754bf52](754bf52))


### Bug Fixes

* access/delegate checks hasStorageProvider(space) in a way that
provider/add allows access/delegate
([#483](#483))
([f4c640d](f4c640d))
* adjust migration 0005 to keep delegations table but create new used
delegations_v2
([#469](#469))
([a205ad1](a205ad1))
* adjust migration 0005 to not do a drop table and instead rename
delegations -> delegations_old and create a new delegations
([#468](#468))
([6c8242d](6c8242d))
* allow injecting email
([#466](#466))
([e19847f](e19847f))
* DbDelegationsStorage#find throws UnexpectedDelegation w/ { row } if
failed bytesToDelegations
([#476](#476))
([a6dafcb](a6dafcb))
* DbProvisionsStorage putMany doesnt error on cid col conflict
([#517](#517))
([c1fea63](c1fea63))
* delegations model tries to handle if row.bytes is Array not Buffer
(e.g. cloudflare)
([#478](#478))
([030e7b7](030e7b7))


### Miscellaneous Chores

* **access-client:** release 11.0.0-rc.0
([#573](#573))
([be4386d](be4386d))

---
This PR was generated with [Release
Please](https://github.com/googleapis/release-please). See
[documentation](https://github.com/googleapis/release-please#release-please).
gobengo added a commit that referenced this pull request 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 <[email protected]>
gobengo pushed a commit that referenced this pull request Apr 11, 2023
🤖 I have created a release *beep* *boop*
---


##
[5.0.0](access-api-v4.11.0...access-api-v5.0.0)
(2023-03-23)


### ⚠ BREAKING CHANGES

* implement new account-based multi-device flow
([#433](#433))
* upgrade capabilities to latest ucanto
([#463](#463))

### Features

* access-api handles provider/add invocations
([#462](#462))
([46da0df](46da0df))
* access-api serves access/claim invocations
([#456](#456))
([2ec16e9](2ec16e9))
* access/authorize confirmation email click results in a delegation back
to the issuer did:key so that access/claim works
([#460](#460))
([fc62691](fc62691))
* allow multiple providers
([#595](#595))
([aba57b3](aba57b3))
* define `access/confirm` handler and use it in ucanto-test-utils
registerSpaces + validate-email handler
([#530](#530))
([a08b513](a08b513))
* handle access/delegate invocations without error
([#427](#427))
([db01d07](db01d07))
* if POST /validate-email?mode=authorize catches error w/ too big qr
code ([#516](#516))
([ab83b19](ab83b19))
* implement new account-based multi-device flow
([#433](#433))
([6152e55](6152e55))
* includes proofs chains in the delegated authorization chain
([#467](#467))
([743a72f](743a72f))
* move access-api delegation bytes out of d1 and into r2
([#578](#578))
([3029e4a](3029e4a))
* move validation flow to a Durable Object to make it ⏩ fast ⏩ fast ⏩
fast ⏩ ([#449](#449))
([3868d97](3868d97))
* provision provider type is now the DID of the w3s service
([#528](#528))
([4cd6cd9](4cd6cd9))
* space/info will not error for spaces that have had storage provider
added via provider/add
([#510](#510))
([362024f](362024f))
* upgrade capabilities to latest ucanto
([#463](#463))
([e375ae4](e375ae4))
* upgrade to new ucanto
([#498](#498))
([790750d](790750d))
* write invocations and receipts into ucan log
([#592](#592))
([d52a281](d52a281))


### Bug Fixes

* access/delegate checks hasStorageProvider(space) in a way that
provider/add allows access/delegate
([#483](#483))
([1d3d562](1d3d562))
* adjust migration 0005 to keep delegations table but create new used
delegations_v2
([#469](#469))
([d90825a](d90825a))
* adjust migration 0005 to not do a drop table and instead rename
delegations -&gt; delegations_old and create a new delegations
([#468](#468))
([89f2acd](89f2acd))
* allow injecting email
([#466](#466))
([b4b0173](b4b0173))
* DbDelegationsStorage#find throws UnexpectedDelegation w/ { row } if
failed bytesToDelegations
([#476](#476))
([660f773](660f773))
* DbProvisionsStorage putMany doesnt error on cid col conflict
([#517](#517))
([8c6dea8](8c6dea8))
* delegations model tries to handle if row.bytes is Array not Buffer
(e.g. cloudflare)
([#478](#478))
([02c0c28](02c0c28))


### Miscellaneous Chores

* **access-client:** release 11.0.0-rc.0
([#573](#573))
([29daa02](29daa02))

---
This PR was generated with [Release
Please](https://github.com/googleapis/release-please). See
[documentation](https://github.com/googleapis/release-please#release-please).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants