Re: Outreach via wikipedia articles on authentication and authorization

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?

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