Re: Outreach via wikipedia articles on authentication and authorization

On Wed, August 7, 2013 06:46, Karp, Alan H wrote:
> Rob Meijer wrote:
>>
>> When I go to the gym, their locker system provides me with a locker
>> number,
>> I can than create my own authorization token (pin) and can than store my
>> stuff
>> in that locker, ones I'm done I can use the authority implied by the
>> locker-number + pin to again gain access to the locker. No identity,
>> no authentication presupposed or otherwise.
>>
> My gym has the same kind of lockers.  Clearly, you can lock your stuff in
> any unused locker, whether it was assigned to you or not.  What's really
> happening is that you are authenticated when you enter the gym and given
> the authorization to use any unused locker with the understanding that you
> will use the one assigned to you.  That's something I didn't mention in my
> description of access control, policy.

At my own gym, yes, I am authenticated when I enter, and my own gym knows
my identity. Last week however, while not in my hometown, I went to an
other Gym (with a similar locker system) a few times, and instead of
authentication bound authority it was a hand full of coins that authorized
me to enter the gym.

IMO, once authority is sufficiently decomposed, attenuated and maybe also
made revocable, the identity of who or what is using it becomes
irrelevant, making authentication not only unneeded, but in fact
undesirable.

In my view the locker system is an example of decomposed revocable
authority that resulting from the limited authority involved with an empty
locker and the fact that this authority can be revoked in case of DOS,
allows this system to work without the notion of identity or
authentication.

You can look at identity as just an other authority from a POLA view and
ask yourself: "Does this (sub) system require the authority to access the
identity of its user". Further its essential to make the distinction
between (sub) systems that need identity for access control and (sub)
systems that need to do some kind of logging for accountability purposes.
For the later the concept of revocable anonymity can be quite useful.

AnonimityToken=sign(encrypt(randomseed+credentials,IRPublicKey),PrivateKey)

If I was to make a software version of the locker system I guess the above
would be quite useful for combining the nice anonymity properties of the
system while being able to have accountability if one joker would do a DOS
on the lockers by claiming every single locker.

In that case you shill have authentication, but purely for accountability,
not for authorization.