Authorization with SSI: How do we do AuthZ with credentials?

Authorization with SSI: How Do We Do AuthZ with Credentials?

Tuesday 2D

Convener: Jacob Siebach

Notes-taker(s):

Tags for the session - technology discussed/ideas considered:

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Difference between Access, Authentication, Authorization

How do we really do authorization with credentials?

Authentication and Identity

A lot of authentication does not have to do with identity eg. student getting a discount at a bookstore

-> you are authenticating with identity. identity as set of attributes

identifiable attributes

Authentication = Provenance

indirection (prove your identity, then use that to prove you are what you claim to be) causing problems -> directly prove claims with verifiable credentials

Verifiable Credentials can bypass Authentication to get Authorization

Also be able to delegate someone to act one one’s behalf (with VC)

Replay needs to be protected

can’t stop replay without authentication

If there’s delegation, you can delegate someone to buy someone under 20 to buy beer

-> responsibility tracking comes together

Technical artifacts make sense when it follows patterns of contract and sub-contract

problem with Attribute-based access control: you cannot know what kind of access you are delegating

Dima Postnikov:

Don’t you authenticate to get a credential (1) as well as potentially to authenticate to retrieve the credential for presentation (2). As well as authenticate to delegate (3) if required.

There are multiple points authorisation happens too: when credential is issued (1) and when credential is used (2)

Benedikt Olek:

You need to authenticate, otherwise other people can you VCs (e.g. Verifiers you shared the VCs with in the past) You can only skip authentication when you have other (e.g. non-SSI-protocol) means of authentication and a secure communication channel

There shouldn’t be an authorization token. They can be stolen. Authorization system should not give you a token

What is replacing a token? -> in the bookstore example, the bookstore calls the AS to check if discount is available -> How is it proved?

“confused deputy vulnerability/problem”

Service Chaining problem cannot be solved by authentication approach, needed an authorization approach

you have to have preexisting relationships with the RS, it prevents a lot of ad hoc collaboration

“13+2 problem”: there were 400 attributes used in the Air Force, they could get a consensus on what the attribute meant for only 13+2 attributes

on SSI:

SSI is supposed to unify offline/online experiences. How we do it offline should also work online.

SSI enables you to choose which attribute will be attached to which DID (= selective disclosure)

micro-credentials

what is the decentralized mechanism that provides authorization?

authorization depends on the service provider

capability-based security

ocaps

a system that actually is working

two things are critical:

attenuated delegation

chaining

If every object knows the access policy for everything, you can work around it, but if you cross organization borders, it breaks.

(OCAPs talk was given at the last IIW)

Proposal at Kantara: naked VC is almost useless, need to tie it to a certain (context?). made a proposal in the healthcare domain. http://kantarainitiative.org/confluence/display/WT/Draft+Recommendations

good thing about VC: you can provide a subset of the credential

identity: need an out-of-band mechanism to track down someone’s identity to do responsibility tracing

if you give somebody’s DID, that’s a big deal, but you can delegate part of your VC

Q: are we sacrificing decentralization by solving authz/authn?

no. there are certain authorizations that is not tied to an centralized authority

Delegation chain, just like creating an intermediate certificate chain

VC and SSI only come in when deciding whether to give it to someone. that doesn’t have to be in the certificate

Each delegator makes a decision based on whatever the delegator wants. don’t need global agreements. we are delegating authorizations, not the VCs themselves

If you try to block delegations, it will result in a more insecure system, people will start sharing credentials themselves. People used to share login credentials!