DIDAuth + Obj. Cap.

From IIW

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

https://alanhkarp.com/

(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://curvecp.org/


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)


TH1G.jpg