Re: Outreach via wikipedia articles on authentication and authorization

On Wed, August 7, 2013 23:02, Dirk Pranke wrote:
> I'm not sure if I understand you properly; it seems like the transitivity
> of properties gets fuzzy here, in ways that are important to clarify.
>
> For example, suppose you authenticate to a system, and as a result get a
> capability to some resource. In this sense one would say that you are
> authorized to access the resource (until such time as the capability gets
> revoked).
>
> However, if I can somehow get this capability, I can also get access to
> the
> resource. I would normally say that my access was unauthorized (and that I
> am unauthenticated). But, if the capability *is* the authorization, this
> seems not possible?

The point is "somehow get this capability" often means you have
abstraction leakage. Basically the only way to dynamically get a
capability to an object you did not create should be trough 'explicit'
delegation.

This brings us to a second piece in the accountability puzzle. You can
delegate with or without identity. If you delegate to an anonymous entity,
than authority is delegated but accountability is not. For highly
attenuated chunks of authority this is not a problem and using identity
would in fact
be a violation of POLA. In those cases however where a larger chunk of
authority needs to be delegated, (partially) delegating accountability
with
authority can become essential, and in order to do so, some kind of
identity or at least some kind of revocable anonymity token is required.

B.t.w, discussing this, and thinking about the Horton/Mailkey based
identity concepts, how about looking into a Horton/Mailkey based/inspired
revocable anonymity design? I think we should look into further
attenuating the need for and use of identity in cap based systems, and if
a Horton/Mailkey inspired pattern could maintain the property of
transferring accountability with delegation without actually unduly
delegating knowledge about identity, that IMO would be absolutely amazing.
Does this make sense?

> Continuing your example, if I steal your car keys and drive off in your
> car, the car might "think" I was authorized, but you (and most people)
> probably wouldn't?
>
> -- Dirk
>
> On Tue, Aug 6, 2013 at 8:45 PM, Marc Stiegler <[email protected]> wrote:
>
>> Authorization does in fact presuppose authentication. But the
>> authentication may have taken place much earlier. One way we describe
>> ZBAC
>> is, one authenticates at time of grant, and then at time of access the
>> resource only needs to check the authorization. This is how car keys
>> work:
>> I authenticate you by looking at you when I hand you the keys. Then the
>> car
>> does not need to know who you are, it only knows, and only cares, that
>> you
>> are authorized.
>>
>> Perhaps some flavor of the above set of words could be used as a link
>> not
>> only to the existing authorization section, but also to a new entry on
>> authoriZation Based Access Control?
>>
>> --marcs
>>
>>  On Tue, Aug 6, 2013 at 11:22 AM, Mike Samuel
>> <[email protected]>wrote:
>>
>>> If it's on topic, I'd like to start a discussion about how to make
>>> sure websites that are cited for basic security definitions don't
>>> prejudice developers against ZBAC.
>>>
>>> Wikipedia is widely read and often cited for basic definitions on fora
>>> like stackoverflow, so making sure it's accurate might help elevate
>>> security discussions.
>>>
>>>
>>> The page on Authentication (
>>> http://en.wikipedia.org/wiki/Authentication#Authorization ) says:
>>>
>>> > The process of authorization is distinct from that of authentication.
>>> > Whereas authentication is the process of verifying that "you are who
>>> > you say you are", authorization is the process of verifying that "you
>>> > are permitted to do what you are trying to do". Authorization thus
>>> > presupposes authentication.
>>>
>>> That last sentence is widely believed and contributes to poor software
>>> design, and the use of personal pronouns in the second sentence slips
>>> in all kinds of identity-related baggage.
>>>
>>> I'd like to edit this section, but having my changes survive later
>>> editors requires respecting the scope of the containing article on
>>> Authentication.
>>>
>>> Does anyone have any thoughts on what to include and what not?  I
>>> looked through "From ABAC to ZBAC" for some punchy pull quotes but
>>> didn't find anything short that stands alone.
>>>
>>>
>>> http://en.wikipedia.org/wiki/Authorization does mention capabilities
>>> and POLA but a naive reader could still read that and reasonably come
>>> to the conclusion that "authorization presupposes authentication."
>>>
>>> It might be good to link from "Authentication" to a  fragment of the
>>> "Authorization" page that contrasts the two and includes examples of
>>> systems that the web-dev set might aspire to build that do ZBAC, but
>>> there is no such section exists today.
>>>
>>>
>>> http://en.wikipedia.org/wiki/Access_control has
>>> > Subjects and objects should both be considered as software entities,
>>> > rather than as human users: any human user can only have an effect
>>> > on the system via the software entities that they control.[citation
>>> > needed]
>>> buried half-way down the page, but it really does need a cite, and the
>>> article starts off with a bunch of anthropomorphic analogies.
>>> _______________________________________________
>>> cap-talk mailing list
>>> [email protected]
>>> http://www.eros-os.org/mailman/listinfo/cap-talk
>>>
>>
>>
>> _______________________________________________
>> cap-talk mailing list
>> [email protected]
>> http://www.eros-os.org/mailman/listinfo/cap-talk
>>
>>
> _______________________________________________
> cap-talk mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/cap-talk
>