It mentions Spritely and CapTP. It also mentions icap, which I haven’t read but have printed out for later. Anyone look at icap before?
From the skim I did do of the two posts, I’m seeing some overlap between this and the certificate, especially linked data, approach to ocaps, in that a subject is mentioned. (But of course, @alanhkarp reminds us that the subject should matter a lot less in certificate ocaps, because you should ideally generate a new key relevant to every capability grant. I don’t think this has been happening in practice by implementors of the certificate approach recently though.)
I found “Distributed Authorization” to be naive in several dimensions, particularly time and revocation. It’s clear that Jens needs to read MarkM’s thesis and at least one paper on certificate-based capabilities.
Li Gong’s icap idea is flawed because he ignores the possibility of credential sharing. His model for controlling delegation is nothing more than OAuth token exchange with a policy that allows denying the request, an example of Do Not Delegate. That policy makes the (I think unreasonable in an open system) assumption that all identities are known to the access control server. Even if they are, credential sharing gets around any such policy. I believe that MarkM has a more comprehensive debunking of this paper.
Crucially, though, OCAP did not really consider the identity of the caller to be of any importance. Later work such as Li Gong’s ICAP did put their focus on such issues
“did not really consider”, “Later work”, gets the history so wrong as to be laughable.
But may as well spice it up with casual dismissal:
It’s hard to take OCAP seriously as a distributed authorization mechanism in and of itself. Of course, modern interpretations such as CapTP’s underpinnings are quite different in nature.