I will just leave this here as a stub - I have not properly thought this through.
Many services in the IPFS ecosystem (eg textile’s ThreadsDB, Powergate) or Filecoin Lotus work with a JWT to authorize API access (derived from a PeerId where applicable ThreadsDB, Lotus?).
It feels natural to explore - in later iterations ! - where adding support for UCAN natively can make sense.
note: UCANs are user-centric and user-issued, but I don’t think there is a fundamental objection to issue UCANs from a service, in a more JWT-like fashion.
In particular when it concerns access to a service, it might be valuable for having a root-service issuing delegation to a user, which can then be revoked. Eg. in UCAN v0.5 permissions can be merged, so merging inate permissions originating from the user, combined with permissions delegated to the user, can be combined to effect actions.
Why? In the current proof-of-concept phase I will manage middleware which handles JWT to talk to Lotus/Powergate on one side, and UCANs from the user on the other hand.
Counter-argument: because JWTs exist, having a component which gracefully stitches JWTs to UCANs seems worthwhile to have too. So why rewrite JWTs where they solve the problem?