Re: identification, authorisation, authentication

Poor Richard wrote:
> Nathan, I defer to your identification/authorization process veiw from a
> particular implementation standpoint and I don't mean to quibble with it,
> but from a more general level of abstraction my perspective is this:
> 
> Identification consists of up to three parts when some resource or
> transaction request is received:
> 
>    1. asking for a properly formatted ID (if not already satisfied in the
>    original transaction request)
>    2. the original transaction-requesting agent providing (asserting) the
>    requested ID
>    3. authenticating (confirming) the provided ID.
> 
> 
> Under some circumstances an ID might be authenticated (accepted) on the
> strength of a trusted format in which an ID is provided. In other cases
> some additional steps might be involved in authentication. For example, a
> driver might present a properly formatted drivers license but the cop may
> not accept it at face value and may use a computer to verify it and might
> also look for associated information such as outstanding warrants.
> 
> So I see authentication as part of the full identification process, which
> is then followed by an authorization process.

I think the difference here is that I see identification as part of the 
full authentication process (rather than authentication as part of the 
identification process), and critically: authentication as providing a 
verified identifier for the authenticating agent.

To illustrate, consider the Oauth flow:
   https://developers.google.com/accounts/images/loginflow.png

In this case, Identification of the agent, to the application, is 
provided at the end of the authentication flow.

Generally, authentication factors include something an agent has, knows, 
or, does. Or multiples of those factors. Authentication may be 
delegated, and multiple authentication mechanisms may be offered to an 
agent. Each mechanisms requirements, and which mechanisms are offered, 
is an implementation detail. Perhaps then the Authentication interface / 
authenticate function I mentioned, may be the thing which hides all of 
those details, leaving only the required bits, a function which wraps up 
authentication, and which returns a verified (or more accurately 
authenticated) identifier.

Thus I would suggest that the 3 points you mentioned are implementation 
details hidden by this interface, and a level below choosing which 
authentication mechanism to use.

Make sense?

> In the most general terms, authorization consists of:
> 
>    1. predefining the authorization conditions and access permissions for a
>    given resource or transaction
>    2. granting access to a resource or transaction based on a the
>    requester's proper identification and the predefined conditions
> 
> Most likely I have left out some possible steps or details, but I am
> suggesting such a big-picture generalization on the theory that such
> context might be used to help make different identification/authorization
> implementations more inter-operable.

Exactly, that's what I'm also hoping to achieve, even if it's just a 
common understanding between the members of this group.

Thanks for replying and talking this through,

Nathan

> Regards,
> PR
> 
> On Tue, Oct 30, 2012 at 8:40 PM, Nathan <nathan@webr3.org> wrote:
> 
>> This may seem like first year stuff, but it may be useful to mention.
>>
>> Identification != Authentication != Authorisation .
>>
>> Generally we can say that Authentication provides us with an identifier
>> for the authenticated agent, and Authorisation is then done using the
>> authenticated identifier.
>>
>> API wise, this means we have:
>>
>> Interface Authentication {
>>   agent-identifier authenticate(*);
>> }
>>
>> Interface Authorisation {
>>   boolean authorise(agent-identifier vai, request r, *);
>> }
>>
>> Step one is to authenticate the requesting agent and establish an
>> agent-identifier for them.
>>
>> Step two is to see if the established agent-identifier is authorised to do
>> what they've requested.
>>
>> WebID-Protocol implements the Authentication interface, and returns a
>> specific kind of agent-identifier, namely a WebID.
>>
>> WebAccessControl implements the Authorisation interface.
>>
>> When working on the web, it makes sense that an agent-identifier be a URI
>> (of which WebIDs are a subset).
>>
>> This decoupling means that WebAccessControl doesn't require a WebID,
>> rather it just requires a URI identifying an agent.
>>
>> I'm only mentioning this because sometimes when you look at things closely
>> for a long time the simple stuff gets all mixed up. Or perhaps more
>> accurately, writing the above clears things up in my own head and allows me
>> to both share it and sanity check it with the group :)
>>
>> Best, Nathan
>>
>>
> 
>

Received on Wednesday, 31 October 2012 11:01:55 UTC