access service & client should use did:web:web3.storage

[gobengo]

Motivation:

• towards Use same did across access / upload API services #183
  • does the 'access' part

Parts

• upgrade to @ucanto/{interface,principal} 4.0.0 which is required to use non-key DIDs feat!: upgrade to @ucanto/{interface,principal}@^4.0.0 #238
• update access-api to create a ucanto server with a principal whose id is did:{newServiceDid}
  • feat: access-api uses DID env variable when building its ucanto server id #275
• update access-client connection factory to use did:{newServiceDid} as default principal
  • or at least make the new well-known principal id/key values be easy to import so e.g. w3ui doesn't have to hardcode them
• test-ucanto-connection dev tool in access-client cli to test the ucanto connection by sending an invocation to the expected id
• update cli test-ucanto-connection to send invocation to new access id (i.e. did:{newServiceDid})

[hugomrdias]

is this the same #182 ? can we add this to the track issue ?

[gobengo]

@hugomrdias it's part of that, but just the part for access-client and access-api. that ticket is for 'all the services' afaict.

can we add this to the track issue ?

sure idc. I put it in the equivalent milestone so it appears in the gh project board

[hugomrdias]

why did:web instead of did:dns ? @gobengo @Gozala

[gobengo]

why did:web instead of did:dns ? @gobengo @Gozala

@hugomrdias only prior discussion was here.

In short, it's because did:web is easier to implement and try things out with.

• implementable using only a web server, which access-api and upload-api already are
  • did:dns impl would beg question of how to manage the dns rules, which depends on how we operate our dns server and whether we outsource it e.g. to cloudflare or route53
• did:web spec is maintained by members of w3c ccg, which is a group we can go to for advice while implementing. did:dns spec maintained by one company atm (even though it's a rad company :P).
• Things I'm avoiding on purpose in did:dns
  • this TODO gives me pause
  • dns rule resolution is eventually consistent and did:webfetch isn't
  • did:dns vulnerable to spoofs without DNSSec, and I didn't want to bite off DNSSec support unless we really need to
• Most importantly, if did:web starts feeling like a bad choice, we can stop using it and try anything else.

[gobengo]

I think this is done now :)