Re: identification, authorisation, authentication

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.

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.

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
>
>


-- 
*
Poor Richard's Almanack 2.0 <http://almanac2010.wordpress.com/>

There is no answer. There is no solution. There is only practice. (anon)*