Filecoin Ecosystem, 30 Mar 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Ecosystem-WG March 2022 Deep Dive: UCAN Auth in NFT.Storage [NFT.Storage]

Description

The Ecosystem WG is a collection of 80+ people across 5+ organizations that are passionate about the long-term adoption of Web3 and dedicated to growing the Filecoin, IPFS, and libp2p ecosystems.

We regularly host all-hands meetings to check in on progress and showcase the growth of various developers, applications, storage providers, clients, and communities around the world.

This deep dive features Hugo Dias on the NFT.Storage | Nitro team demonstrating UCAN Auth in NFT.Storage is an integration with fission’s UCAN authorization, a cryptographic way for NFT.Storage users to delegate others to upload on their behalf

Check out more about NFT.Storage & UCAN here:
https://nft.storage/
https://github.com/nftstorage/ucan.storage
https://ucan.xyz/
https://twitter.com/nft_storage
https://discord.com/invite/KKucsCpZmY
https://github.com/nftstorage

If you, your team, or organization want to be a part of our working groups or would like to present and be featured in our next public All Hands, please reach out to: ateam@protocol.ai.

A

So and talk a little bit, I'm going to talk a little bit about eukans and how we use them in nft storage and soon in where 3. started to to do authentication.

A

So, first, this all came up because we had we had a an issue, a problem with the with service, and this came specifically from our users.

A

We, when we built the service, we like our api and the authentication of the api, was a basically a really basic type of system, with only api keys uh and those api keys cannot really leave in a web browser or any unsecured type of device or computer.

A

So this was a request from our users. They wanted to to have an easier way for them to kind of allow the their users. If we were talking about the marketplace being the user of nft storage, they wanted to allow their users to um upload directly to us, because if we don't allow for this, they actually need to proxy everything uh through their own services through their own infrastructure. So we are basically duplicating the bandwidth they create.

A

They need to create extra services and proxies for all of the traffic they they need from the end users. They have uh so yeah just a small uh diagram uh about to explain this. So um the the marketplace needs to request an api key from us and that's how how they interact with our api. We send them the api key and they need to keep it secret.

A

You need to save it, uh one password or whatever or in whatever way they want in their backend, but it needs to be secured, needs to be on a back-end type of service. Where can they can provide the security they need? um And then, if the user needs to upload something they need to go through the the marketplace back and and then the marketplace back-end needs to send the data to us. um So this is a little bit uh web tool and we wanted something better.

A

So the solution um that we are implementing is uh you can't you can um uh so it's basically user, controlled authorization network and the the spec for this was made by uh vision um and we we actually contributed a bit to the spec and we are collaborating on. On the whole. You can ecosystem a lot right now, so this you can's are a trustlessly, secure, local, first user, originator, authorization and re revocation scheme.

A

uh These will achieve this public ver verifiability with chain certificates and that decentralized identifiers or the ids, and we can actually have a verifiable shame compression using content addressing and see ids directly. I will explain a little bit better later how this can be done um and specifically for us. um We issued our ucans to our users and they basically contain the permissions uh and the shame of proofs uh that they need um to do an upload request and the thing the the cool thing about this is you can't can be delegated.

A

So if we issue what we call a route you can from our service uh to a marketplace, they can use that you can and delegate from that another one with a smaller set of permissions or with an expiration date, um and they can create a new you can and that one they can give to to their users directly. So they can upload directly to us and they can. They can own that you can. They can can even generate more.

A

You guns for themselves if they have multiple devices and they can keep whatever permissions the the marketplace gay uh gave them.

A

um So it's a little bit more decentralized and the users are more in control, either being the use of the marketplace or being the user, the the an end user uh going to a website and trying to to upload a file to internet and nft.

A

uh So in this slide, I'm going a little bit deeper on this, so um to explain how the the whole flow, uh how the whole flow works. You can see in the in the diagram on the right. If we start from the service, um we need to know like the first actor- uh and this is like at the top. We need to know the marketplace. The service needs to know what the marketplace, so the marketplace needs to give us at least there. The id we don't need private keys. We don't need nothing.

A

We just need the public key or the id from from them, and with that we sign one, you can token for them specifically for them, because they just gave us their the id. So we issue and sign you can to them uh and we give them uh full capabilities they they. They actually have an account with us. They are like the root user of uh you can chain of responsibilities.

A

um So we issue a what we call a root you can, with all the capabilities normally or at least for now. We issue them with a an expiration date of two weeks, uh but they can basically refresh this token whenever they want and keep keep it uh fresh and active.

A

You can see an example on the on the left uh to see how this first, you can looks like um so then the marketplace, um then this route you can uh actually uh they actually need to to keep it safe. Because it's the route you can it's, it has all the capabilities.

A

They cannot just share this one and they shouldn't that's, not how you can works and it will fail validations afterwards. They should not share this.

A

You can with anyone what they is. What they can do is is to sign a new you can, for their end users, as you can see in the diagram here. So the end user needs in the same way needs to provide the id to the marketplace. Just that no need to exchange files, nothing just the ide and that can can can live inside the marketplace.

A

Own authentication flow in their login their accounts, um so it should be seamless for any marketplace to implement and what what they do is that they sign a new you can for this user and they they they put in the property, called the prf, which is basically proofs.

A

The first you can the one they uh we gave them, and this with this we can have. We can building up a chain of proofs, as you can see in the in the in the diagram. You have this signing sign, you can for the marketplace, sign you can for alice and sign you can for service.

A

So this is basically our shame, um and here they can build up a little loop because they don't want to give tokens that don't expire, because maybe they are giving them to be used inside the browser or any insecure type of environment, and they actually can only can issue not only short-lived. You can't, but they can also issue a you can with a subset of capabilities.

A

So on the first you can we actually give the marketplace all the capabilities, but the marketplace can reduce debt for their end users and and just allow them to do an upload and that's it they can even restrict um which uploads they they allow them to do.

A

If they, the the end user, sends them a multi-ash or some kind of ash. They can also include that in the you can and then, when the upload uh arrives at in nfl storage, we can even validate that so there's a lot of constraints and features that we can encode in this system and this in this flow and at the end the end user needs to sign a new uca, and this is really important. uh The la because, uh even when we were researching all of this, uh it's um me included this last step.

A

I uh it took me a while to understand why this is so important. um Every actor in this flow needs to sign a you. Can there's, no there's, no like reusing something I just got and just send that that cannot happen. Every actor needs to get something from another actor, even if it's themselves like issuing to another device and need to sign again.

A

So in this way we actually built uh the the complete shame until we end up where we want to upload something- and that's the the last one, this last one in diagram where it's a sign you can for the id service, um and in this you can you you we actually the audience of this. You can is nfl storage, so they need to put our id there. And now the id is public. They can just get get it from our api or website without any authorization or anything, it's completely published.

A

It's our public key and the others needs to be us. So if it's not, we will not validate it, but building all of this at the end, the user can just sign you can with us as the audience they need to tell us. Okay, uh I want to do an upload, so the only capability in this ucan is the upload slash imports.

A

They need to include the proof, and the proof is the the you: can they got from the marketplace and they can upload directly to us uh this way we we kind of we allow for all the actors in the in the our ecosystem to actually uh handle all the authentication in um well in many ways- and you can also see this like when I'm talking about proofs this. This shame doesn't need to be like a list. It can be a a actually a dagger or a tree.

A

We can include proofs more than one proof in in a you can token. So we can even merge, like you can from an x, dot, storage or wavefield storage, and the marketplace can put both as proofs on the you can they are issuing to to their users and then their users can decide. Oh, I want to upload to and thrilled storage or I want to upload 20 storage and they have that capability. Just with one token, they don't need to come, come to us to create an account.

A

They don't need to to go to the marketplace, to ask for another token specific for this service, um and this is basically uh the the big feature of ucats uh is that we can uh merge a bunch of capabilities from a bunch of actors uh and just delegate delegate them as much as we want and also being able to constrain them as much as we want to reduce the the either the the expiration date or the capabilities that we delegate um and all of this is easily encoded um in one example.

A

This is a very simple example. This is the one that we act. We actually have implemented, and it was the one that we actually wanted to solve, because this was a request from our users, but this can be a lot more complex than this and being a lot more powerful.

A

um It's actually really really awesome um and yeah. That's basically it here. You have some resources, there's the first one. Is our uh library that implements our keep our the capabilities specific for nft.storage?

A

uh It also also implements a little bit of the validation we do in the in the service in the api itself and the other ones, the spec some sites from from vision where you can find all the information about you can't and how they work and all the capabilities they and they allow.

A