DIDAuth + Obj. Cap.
DIDAuth + Obj.Cap.
Day/Session:Thursday 1G
Convener:Orie Steele & Alan Karp
Notes-taker(s): (1) Orie Steele & (2) Matthew Hailstone
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
Hosted by Alan H. Karp and Orie Steele, with notes by Orie Steele and Mathew Hailstone
(1) Notes from Orie Steele:
What is DIDAuth and how is it compatible with Object Capabilities?
We started by defining and describing object capabilities:
A Capability is a Transferable Unforgeable Permission. It can be implemented with unguessable URLS or signed objects.
A Java Program object reference is a capability, it allows for actions on the subject (the object instance).
A stronger implementation of object capabilities involves a digital certificate issued by a public key, for a resource with a set of supported methods:
Issuer: AlicePubKey
Resource: did:dad:0x123
Actions: Read,Write
Signature: 0x456
See attached image or tweet https://twitter.com/OR13b/status/1055540084106190848:
Public key creates a certificate that you give to a colleague that allows them to do work (capability)
Brown block is the delegation
Orange block is the use of that delegation
Object capabilities support Chained Attenuated Delegation.
President > General > Major > Private
Private does not have rights of president, and does not need to ask him or permission to act.
Its impossible to prevent delegation, so its critical that users or agents be thoughtful and be prepared to take responsibility for the actions of a delegate.
Its often preferable to be fine grained w.r.t. actions, so that revocation can also be fine grained.
We discussed the security model of a resource domain:
Identification
Authentication
Authorization
Access Decision
AuthN occurs at Grant NOT at the Use when using object capabilities.
DID AuthZ ~= Object Capabilities (could be!)
DIDAuthN supports mutual authentication in 2 ways:
Simple nonce + challenge signature flow between 2 DIDs (has privacy issues).
Authenticated Encryption (Diffie Helman / Group Key) produces a symmetric key for use.
Some discussion over the validity of NonReputability ( there is no legal protection afforded, the term was created by cryptographers, and may not be helpful, but some people believe it is valuable).
2 Main issues arise when attempting to provide AuthZ for microservices:
Confused Deputy -> https://en.wikipedia.org/wiki/Confused_deputy_problem
Gross Violations of Least Privledge -> https://en.wikipedia.org/wiki/Principle_of_least_privilege
When Object Capabilities are leveraged these issues are addressable within a system for decentralized microservices. ACL or Authentication related approaches are problematic.
Sam Smith mentioned using CurveCP for DIDAuth.
https://github.com/SmithSamuelM/raet
Pelle from UPort mentioned waterken a system for object capabilities:
https://stackoverflow.com/questions/17297632/automatic-persistance-of-node-js-objects-in-database
Also uPort has an OpenID Connect related JWT implementation of Object Capabilities, that might be more compatible with legacy systems.
Alan mentioned https://w3c-ccg.github.io/ocap-ld/
Orie Steele closing thoughts:
I left desiring a concrete implementation of DIDAuth + Object Capabilities potentially built with CurveCP, maintained under https://github.com/decentralized-identity/ and supported by the community.
We should support both a JWT and DID + JSON LD implementation for both modern P2P and legacy systems.
(2) Notes from Matthew Hailstone:
Object Capabilities / DID-Auth
What is a capability?
Take your keys and hand them to someone else in order to allow them to drive the car.
Enabling delegation of authorization to do something
URL with an unguessable string
Java program
Reference to another object is a type of capability
Public key creates a certificate that you give to a colleague that allows them to do work (capability)
Brown block is the delegation
Orange block is the use of that delegation
Attenuation
Chained attenuated delegation
Do AuthN and AuthZ at every request
4 steps to Access Control
- Identification
- Authentication
- Authorization
- Access Decision (at the resource at the time of the request)
Two things to protect
- Bearer token
- Revocation could be like a chain
Put the revocation on the blockchain and the distributed resource can check the blockchain
Not revoking the key, but revoking the delegation
DID-Auth
AuthN
DID uses a key to sign a nonce to another DID
(mutual authentication)
(authenticated encryption - sign cryption)
group key
diffy helman and key exchange
produces a symmetrical key
has the symmetrical key
hash the plain text
hash the cypher text
curve CP (daniel bernstein)
alanhkarp.com
SOA identity identification
zbac
water ken (ethereum)
