Do we need to adopt a capabilities-based delegation model?

[msporny]

There are a number of places in the spec where we list DIDs or public keys that are used to authorize certain actions like DDO modification, authentication to Verifiers/Relying Parties, etc. In each of these places, we seem to be gaining ambient authority problems. We will most likely want to take a capabilities-based approach to the security model across all Blockchains lest we fall into Access Control List and Confused Deputy hell.

We should explore how Macaroons could be used to accomplish delegation.

[ChristopherA]

One of the top capabilities experts, Mark S. Miller (@erights) , will be at the next #RebootingWebOfTrust in Boston. We have had two other capabilities experts at the first #RebootingWebOfTrust, Tyler Close (@tjclose ?) who wrote https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust/blob/master/topics-and-advance-readings/AvoidingConfusedDeputyAttackUsingCapabilities.md and Dominic Tarr (@dominictarr) who submitted https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust/blob/master/topics-and-advance-readings/key-exchange-as-capability-system.md — there was one more person from the capabilities community at IIW that was also interested, but I can't find his info.

Maybe we can get one of them to review the DID spec and some of the more recent observations from the BTCR hackathon and propose a capabilities approach, or at least talk about it in a future W3C Credentials CG meeting? Or wait and talk to Mark at #RebootingWebOfTrust

[kimdhamilton]

Summary from Manu: Current DID spec distinguishes between ownership and control. Problem is that, in implementation, there's no difference; anyone with proof of control has proof of ownership.

Veres One instead calls out which proofs are used to do what. Primarily, it separates concept of authentication and authorization.

This approach is the one used by W3C, IETF, and other security standards, and it's the proper way to layer these concepts.

[dckc]

Techniques that separate authorization from authentication are traditional, yes. But they're usually not capability systems. In a capability system, if I have a capability, you don't need to care who I am when I make a request. The fact that the request is made using a capability means that it is authorized to exercise the capability.

A capability system may well have an authentication component somewhere, but a key pattern is:

With ocaps, you authenticate at the time of grant, but not at the time of access. -- marcs Nov 2011

A problem with separating authorization from authentication is: if you're selling me a stick of gum, all you care is that I have a nickel. But if you're updating my DNS record, it's cost-effective to go to much greater lengths to ensure the request is authorized. In a system that separates authentication from authorization, it's typical for a request to go through an authentication wrapper that throws away all the actual credentials and passes just a name on to next level. So the gum-selling function and the DNS-updating function end up with the same info: my name (i.e. account name).

Code like this is typical:

if request.user.is_authenticated:
    # Do something for authenticated users.
    ...
else:
    # Do something for anonymous users.
    ...

https://docs.djangoproject.com/en/1.11/topics/auth/default/#auth-web-requests

But in an ocap system, if a call is made to a method on an object via a capability, the call is always authorized. If it were not authorized, the caller would not have a capability / reference to the object.

[msporny]

Hi @dckc, long time no talk! You are, of course, correct. We just had a big event (Rebooting Web of Trust 5) to dive deep into capabilities w/ Mark Miller (Project Xanadu, ocap fame) and have a series of modifications to the DID specification as a result. The current status is that the group is adopting capabilities as one security mechanism for most DID supporting ledgers/blockchains as well as experimenting with it for delegation and attenuation of Verifiable Claims/Credentials.

As an aside, is this something you'd be interested in participating in? Our next face-to-face is on the West Coast in February. @timbl was at our event last week. More info here: http://www.weboftrust.info/

[msporny]

@dckc just saw this https://github.com/kumc-bmi/grouse -- we really should have a chat soon. The Verifiable Claims stuff we're working on at W3C may be closely aligned w/ what you're doing w/ GROUSE. If it helps, I may be in the KC area around Thanksgiving or Christmas if you have a spare hour or two to meet in person.

[dckc]

Hi @msporny ... yes... long time. This issue looked like a good way to get in touch; glad it worked out...

I do capability security stuff in my hobby time, mostly. I use it at work some, but I'm mostly constrained to use ACLs of all sorts: unix, Oracle, drupal, etc. See also My Capability Security 2017 Wish-List and https://github.com/dckc/awesome-ocap .

I'm somewhat interested to participate; I've been trying to steer things toward ocap since I saw WebID. But I doubt a trip in Feb is feasible.

GROUSE is very much day-job stuff. But the claims there are Medicare / Medicaid insurance claims. I'd be surprised if there's any relevance to decentralized identity stuff.

[msporny]

GROUSE is very much day-job stuff. But the claims there are Medicare / Medicaid insurance claims. I'd be surprised if there's any relevance to decentralized identity stuff.

Not decentralized identity stuff... verifiable claims stuff... Medicare/Medicaid insurance claims are very much in scope... been collaborating w/ some folks at HHS ONC... one such use case here (sorry for the market-y site... but you should get the idea): https://veres.io/use-cases/verifiable-prescriptions/

[dckc]

I don't see any claims data (i.e. billing records) in that use case. There's a tangential connection, but mostly my work is supporting researchers in doing health data analysis. The figure on https://informatics.gpcnetwork.org/trac/Project/wiki/GROUSE might be a good capsule summary.

[msporny]

The group has asserted that delegation is out of scope for the DID spec itself. So the answer to the initial issue is: "The question is out of scope".

That said, there are a number of people working on Object Capabilities for use in DID Documents: https://w3c-ccg.github.io/ld-ocap/

The Veres One DID Method will use Object Capabilities to do delegation/attenuation and we're currently implementing that. So, the work proceeds elsewhere and for the time being, this issue is closed for the group as it's out of scope for the 1.0 version of the spec. We may revisit this in the future if it seems like the ocap approach is one that all DID ledgers will adopt as a best practice.

[msporny]

Veres One has now successfully implemented Object Capabilities: https://w3c-ccg.github.io/didm-veres-one/#authorization

Veres One is a pure Object Capabilities based DID Ledger: https://veres.one/

[erights]

First, @msporny , congrats!

On github, the link shows as to
https://w3c-ccg.github.io/didm-veres-one/#authorization and works.

For some reason, in email it showed up as http://sites.local/didm-veres-one/#authorization and does not work. Anyone know why this is?

If you are looking at this message in email and the two urls above look the same, look on github.

[msporny]

For some reason, in email it showed up as http://sites.local/didm-veres-one/#authorization and does not work. Anyone know why this is?

Yes, I accidentally pasted a local system URL into the github issue tracker by mistake when I first responded... and that's the URL that github sends out to everyone. The URL above is the correct one.