How does UCAN compare to GNAP from a human rights perspective?

[agropper]

The focus of our work https://github.com/HIEofOne/Trustee-Community/tree/master is a standardized self-sovereign authorization server. That seems consistent with both UCAN and GNAP in many ways so I'm curious about the differences.

GNAP is now pretty close to completion https://datatracker.ietf.org/wg/gnap/about/ DIDs are in scope but referenced to another IETF WG. Capabilities are also in-scope. My principal concern is human rights considerations to avoid forced association with a "platform" a la OAuth. See: ietf-wg-gnap/gnap-resource-servers#54

I tried to add a human rights consideration to the spec ietf-wg-gnap/gnap-core-protocol#434 and failed. I also raised the issue in the IRTF HRPC group: https://mailarchive.ietf.org/arch/msg/hrpc/xP8UUMcHZ--XcPuwPWUm0HiKgVs/

As it stands, the issue seems to be that GNAP MAY be used in a self-sovereign way but that may not be what happens in the wild. I would prefer a protocol that makes decentralization a MUST or a SHOULD. Does UCAN help?

[expede]

Thanks for asking :) UCAN is pretty aligned with that, yes.

UCAN is a certificate capabilities system that is (by default) self-soveriegn and transparent to users. The core protocol doens't depend on identity at all, beyond proving access to cryptographic material, so uses did:key in most places (e.g. nonextractable WebCrypto API keys, passkeys, SSH keys, etc). There's nothing in the spec that prevents people from using other DID methods, but tokens with those aren't guaranteed to work with the broader community.

We don't believe that users will self-host their own naming server, so Zooko's triangle rears its head a bit here. We've pushed questions about naming outside of UCAN, so UCAN works on the key material directly. My company tends to put this resolution in DNS.

It's always posisble to re-centralize decentralized tech (see git -> GitHub), but a core design goal of UCAN is to not require centralized auth providers at all. We don't even have an AS in our diagrams. UCAN is totally P2P by nature, and also works local-first out of the box — no cloud required. You need a capability from the resource directly, and a signature chain.

The downside is that poeple often want to plug into existing systems like OAuth, which means running a translation server that can sign on behalf of the user. I'm comfortable with that as a stop-gap while UCAN adoption grows. Because UCAN is interested in authZ (not authN of identity) any system that uses UCANs doesn't have to know if something is self-sovereign or being done throhgh an intermediary — they work equally well with all of the libraries as long as the capabilities and signatures work out.

We've been getting an increasing number of pings about GNAP recently. It would be interesting to explore mixing GNAP and UCAN services.