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!