decentralized-id.github.io/identosphere-dump/open-standards/authorization
2023-01-15 01:30:53 -05:00
..
gnap.md standards sort 2022-12-16 16:07:05 -05:00
oauth.md continue cleanup 2023-01-15 01:30:53 -05:00
README.md continue cleanup 2023-01-15 01:30:53 -05:00

Authorization Protocols

The diversity of our community is a plus. To begin a conversation on VC access controls, I suggest this short intro to the differences between OAuth 2.0 and GNAP:

My goal is to arrive at a shared understanding of what would be minimum needed to support both OAuth2 and GNAP for securing access to a VC.

oCap

  • Hygiene for a computing pandemic: separation of VCs and ocaps/zcaps
    • You could implement zcap-ld on top of VCs…
    • However, you're actually squishing together what should be a separation of concerns in a way that will become unhygienic. Like a lack of proper biological hygiene, the result is sickness in our computing systems.
    • The observation of "these things seem so similar though!" is true, but you can already make that claim even if you're just looking at the linked data proofs layer. VCs and zcap-ld diverge from there for two very separate purposes: what is said, and what is done.

This weeks CCG teleconference had a great discussion about object capabilities

Alan Karp:  I've been doing capabilities since I reinvented them in 1996 and I want to make sure we get it right, because when newbies start to use them there are plenty of mistakes that can be made

[...] A capability or an OCAP is an unforgeable, transferable, permission to use the thing it designates ... it combines designation with authorization

I was reading zcaps draft, as well as related work, mostly macaroons (https://research.google/pubs/pub41892/.

Something that I found confusing  about capability documents is that they do not make clear the actions they concern. For example from this https://w3c-ccg.github.io/zcap-ld/#example-1 it is not clear that this is a capability for "driving a car".

We are still trying to figure out how to explain these things to people.

Capabilities-based systems are not a new concept; they're decades old at this

point. The challenge has always been in communicating why they're useful and

have a place in modern security systems.

The Encrypted Data Vault work uses zcaps, and it's there that we're trying

hard to explain to developers how to use it:

After ruminating on ZCAPs, VCs, DIDs, and DID Documents over Easter dinner, it occurred to me that we're on the verge of creating a model for a "verifiable" economy...

https://www.notion.soimages/image3.png

I see all of this converging into a Capability Authorization-enabled Decentralized Object Model.  “More news at 11…”

https://www.notion.soimages/image1.png

Updates on Kepler including implementing support for CACAO-ZCAPs, improved the put function to make it easier to store objects of different types, and added support for listing objects by prefix: kepler-sdk#40 kepler#115.

  • The ezcap library - Manu Sporny

    Now might be a good time to announce some open source tooling a few of us have been working on related to zcaps that is being created to simplify the developer experience when developing with zcaps.

  • ezcap (pronounced "Easy Cap") - An easy to use, opinionated Authorization Capabilities (zcap) client library for the browser and Node.js.

UCAN

ucan-wg

these are the types of use cases that we think can be created and enabled across the web as an open, interoperable standard. And some of it crosses into the work we're doing as part of the Decentralized Identity Foundation, too.

  • User Controlled Authorization Network model and how it contrasts with decentralized approaches
  • APAC/ASEAN Community Call now a colloaborative initative between DIF and ToIP, launched Thursday 26th May 2022, kicking off with an IIW34 recap. (Recording A couple weeks ago Amber Case came and spoke about “Calm Technology” at the TOIP Human Experience Working Group (HXWG