Re: Outreach via wikipedia articles on authentication and authorization

On Thu, August 15, 2013 17:22, Karp, Alan H wrote:
> Rob Meijer wrote:
>>
>> Only, if for example, Alice is a program used by me, Bob a plugin used
>> by
>> the program Alice, Carol a library used by the plugin Bob, David an
>> object
>> of a class defined inside of the Carol library, and Mallet a remote
>> active
>> object invoked by David, than what does that mean for your social graph?
>>
> There is still a responsible party for each component.  If you don't know
> who that is, you can't evaluate how much trust you will put in that
> component.  Will you let it store your New York Times password?  Will you
> let it store your Bank of the West password?  You don't know unless you
> know what contract you have with the responsible party and how likely you
> think it is that the contract will be honored.
>
> When I run Alice, a program, I will decide how vulnerable I am willing to
> make myself to Alice based on the (implicit) contract between me and the
> party responsible for Alice, R(A).  If a violation occurs, I will collect
> any penalty from R(A).  If Alice uses Bob, R(A) will collect from R(B).
> Whether or not R(A) is the same as R(B) is irrelevant to me.  If Bob wants
> to track delegations to Carol, that's Bob's concern and nobody else's.
> It's all about encapsulation.

Ok, so where is the identity or authentication in that? So bob could do
responsibility tracking, but given that neither Alice nor Carol is a
person,
neither one has an identity, so neither one could have done any
authentication. As far as Bob is concerned, identities do not exist. As
far as Bob is concerned there is no such thing as authentication. So as
far as Bob is concerned, the Wikipedia statement is completely bogus.

> I think that granularity is a red herring.  I can be quite safe sharing a
> lot of my permissions, say all of my photos, and at high risk sharing a
> very fine grain permission, say the ability to sell my HP stock
> (unfortunately not as much risk as just a few years ago).  The place that
> granularity comes in is that a given party is likely to be responsible for
> a lot of small objects but only a few large ones.  Still, all that matters
> is the contract that I have with the responsible party and the degree of
> vulnerability I have when granting rights to objects that party is
> responsible for.

Funny, in my view its 'identity' that's the red herring, not granularity.
Identity is a single granularity concepts that keeps the discussion locked
to that one single granularity. I'm talking about the granularity of the
entities that are considered to be handling pieces of authority, not the
granularity of these pieces of authority themselves.

IMO single granularity abstractions are a major source of abstraction
leakage, and they keep us from solving problems in a fundamental way. I
believe we need to look for and find a way to think about responsibility
tracking in a granularity neutral way, just like Marks insights on
capabilities helped us to think about authority in a granularity neutral
way. Regressing to the multi-granularity toxic concept of identity and
authentication by claiming that authentication is a necessary precursor to
authorization IMO in that context is anti-productive.


Rob