test registration via access/authorize

[gobengo]

Motivation:

• test feat: add support for access/authorize and update storacha/w3up#392

Insights:

• This test tries to register the space by invoking access/authorize with email address from env var. In practice, I used my email address, clicked the link, and retried, but that doesn't work. I think that's a sign access/authorize doesn't currently register the space in a way that matches my check
  • I can adjust my check and/or we can make it so clicking the email sent via access/authorize writes into the delegations table in a way my check would pass

[gobengo]

#status this test:

• tries to access/delegate for a space, but if it gets an InsufficientStorage error
• it assumes that's because the space isn't registered. And it attempts to register the spaces using email address process.env.W3S_EMAIL (which is my work email).
  • example: https://github.com/gobengo/w3protocol-test/actions/runs/4288078253/jobs/7469657349#step:6:74

Problem:

• If I click the link in the email it sends me and retry the test, I expect the access/delegate to work now that the space is registered, but it doesn't.

Solution:

• Clicking link in confirmation email sent by access/authorize should register the space such that access/delegate invocations are allowed
  • relates to 'delegation 2' of Succesfull access/authorize should delegate capabilities to the agent so it can claim them storacha/w3up#457 (all of this is just trying to get did:key working with no did:mailto at all)

[Gozala]

• tries to access/delegate for a space, but if it gets an InsufficientStorage error

• it assumes that's because the space isn't registered. And it attempts to register the spaces using email address process.env.W3S_EMAIL (which is my work email).

  • example: https://github.com/gobengo/w3protocol-test/actions/runs/4288078253/jobs/7469657349#step:6:74

This does not match my expectations. Specifically trying to access/delegate to check if space is registered seems strange. If we need to check whether space is registered we should probably expose separate capability to do just that.

If I click the link in the email it sends me and retry the test, I expect the access/delegate to work now that the space is registered, but it doesn't.

access/authorize is not meant to do the space registration, it's meant to invoke account authorization flow and if successful result in delegation from an account DID to the agent did as described in storacha/w3up#457

Solution:

* Clicking link in confirmation email sent by `access/authorize` should register the space such that `access/delegate` invocations are allowed
  
  * relates to 'delegation 2' of

I do not think access/authorize should do any kind of space registration, because agent DID been authorized is not necessarily a space DID. Neither authorization implies intent to perform registration. Instead we should just have a separate capability to register space. And that is precisely what provider/add supposed to do when invoking

{
  "iss": "did:mailto:web.mail:alice",
  "aud": "did:web:web3.storage",
  "att": [
    {
      "can": "provider/add",
      "with": "did:mailto:web.mail:alice",
      "nb": {
        // did of the provider,
        "provider": "did:web:free.web3.storage",
        // did of the consumer space
        "consumer": "did:key:zSpace"
      }
    }
  ]
  ...
}

[gobengo]

@Gozala Thanks. I see now that I was mistaken to think that it should register a space. The more important bit is that it should result in some delegation that can be claimed, even when the agent only uses did:key. I made this other PR that I think is more appropriate test #6