Closed travis closed 6 months ago
The proof field of the JSON body is a base64pad encoded
Originally I read this as meaning it was base64 encoded with padding. https://datatracker.ietf.org/doc/html/rfc4648#section-4
It could be good to clarify you mean it is multibase encoded using the multibase encoding for base64+padding. https://www.ietf.org/archive/id/draft-multiformats-multibase-07.html#name-base-64-with-padding-and-mi
❤️ love it - thanks for pushing this!
<3
Worth mentioning what you're doing is web3-storage/RFC#1 (comment)
Yes! Though there's a pretty big difference in the authorization - I'm not "passing UCAN delegation as JWT bearer token" because of the 8KB limit I mention in the thread with Ben above, instead passing the secret there and embedding the delegation in the JSON body.
Can you please define response format?
Yep definitely - added a TODO!
To support users in languages that do not have existing UCAN invocation implementations, we are going to launch a bridge that allows them to make simple HTTP requests with JSON bodies that we transform into proper UCAN invocations.
This follows the specification here: https://github.com/web3-storage/specs/pull/112
Values for authorization headers can be generated using the
bridge generate-tokens
w3cli command proposed here:https://github.com/web3-storage/w3cli/pull/175
UPLOAD_API_DID
andACCESS_SERVICE_URL
environment variables toW3UP_SERVICE_DID
andW3UP_SERVICE_URL
(filed as https://github.com/web3-storage/w3infra/issues/337)