Internet Identity Workshop (IIW) is a semi-annual grass-roots gathering of the digital identity community. It is an “un-conference”, with the agenda for each day co-created by attendees that propose sessions, and vote with their feet to attend the sessions they are most interested in.

The two big themes I noted were Verifiable Credentials (VCs) and Authorization. And there was even a session on how these things could relate to each other!

Verifiable Credentials

A major theme of IIW 38 was Verifiable Credentials (VC’s). The idea dates back to Kim Cameron’s Laws of Identity, coined in 2005, which proposed to put the individual at the center of web identity, and allow them to selectively disclose only the attributes necessary for the service they are trying to access.

The canonical example is age verification. A website that only allows users that are 18 or older doesn't need to know anything about the user, other than that a trusted third party can attest that they are indeed 18 or older. This is in contrast to the kind of disclosure that happens today: to prove that they are 18, the individual presents a driver’s license that includes their name, birthday, and address. In other words, the user has to disclose more than is necessary.

Verifiable Credentials build on some old ideas. “InfoCards”, first introduced in Windows Vista, embodied Kim’s Law of Selective Disclosure by allowing a user to control the attributes they presented to a website. Similar to InfoCards, with VC’s, users can store credentials in a wallet which only contain attributes relevant to the service they are trying to access.

This works by having the credential issued by a trusted third party. For example, a university could issue a credential to a former student for successfully completing a bachelor’s degree. That credential could then be presented to an insurance company that grants their customers a discount for completing a higher education degree. No other information needs to be disclosed in that exchange.

VC’s hold much promise, and are worth tracking.

Authorization

Once again, IIW had a fair number of authorization-related sessions and activities. I’ll go over some highlights.

Authorization 101

Steve Venema presented an excellent “Authorization 101” session. Two concepts that Steve explained really well were “Authorization as part of the Authentication ceremony” and “*-BAC”.

Steve made the observation that a common practice during authentication is to mint access tokens that may contain additional scopes, which are computed based on user attributes or group membership. Steve termed this “Pre-authorization”, which is exactly the right way to think about it. These so-called “authorization” decisions are inherently pre-computed at login time, and are meant to be valid for the duration of a session (or at least until the minted access token expires). This can be a reasonable model for coarse-grained access control with roles that don’t change very much. But it’s not a good model for authorizing access to fine-grained resources with permissions that may change often - for example, documents in a Google drive.

Steve also pointed out that RBAC, ABAC, and ReBAC are all compact ways of representing the full set of rules for answering the question “does user U have permission P on resource R”.

My elaboration on this point: the most exhaustive way to state the authorization rules that determine user permissions to resources is a list of facts in the form of "User 'Alice' can 'read' document 'agenda'". To describe the complete model, you need to specify all the facts for the full cartesian product of Users, Permissions, and Resources (in other words, N = U x P x R facts).

The various *-BAC models (RBAC, ABAC, ReBAC) can be seen as optimizations over the naive approach - they are all different ways of expressing every decision in the matrix, but with a far smaller number of facts.

OpenID AuthZEN: 0 to interop in 6 months

I gave a session on the OpenID AuthZEN working group, and the substantial progress we've made over the last six months: going from inception to an implementer’s draft, an interop scenario, and four interoperable implementations (and counting!)

I described the goals of the WG, showed a demo of the interop scenario, and went over the lessons we learned on how to run fast and get real results in a short amount of time.

The Laws of Externalized Authorization

I also gave a session on why externalized authorization changes the game from traditional authorization. The “what”, “how”, and “when” are all different:

The core principles of externalized authorization become “fine-grained”, “policy-based”, and “real-time” access control. The rest of the Laws are below.

Zero Trust with Zero Data

Phil Windley gave a thought-provoking talk about how the world of authorization could learn something from Verifiable Credentials - instead of storing attributes about the user, perhaps zero-trust authorization systems could rely on VC’s to disclose only what is necessary to make authorization decisions?

ABAC vs ReBAC Smackdown

The final session I hosted was a lively debate about ABAC vs ReBAC. We talked through the pros and cons of various models (RBAC, ABAC, ReBAC), what’s new/unique about each, and agreed that often you need to combine these in order to get the best of all worlds. Which is exactly our strategy with Topaz 🙂

AuthZ meetup

Last but not least, we closed IIW with a meetup sponsored by the community that produces the AuthZ substack newsletter. Rohit Khare did a great job organizing and MC’ing the meetup, and half of the attendees were local bay-area folks that hadn’t attended IIW.

Overall, a fun week in the exciting world of authorization!