Re: identification, authorisation, authentication

Following a conversation we had at TPAC, I personally see identification 
as completely separate from authentication.

For me, identification is the way of selecting one person/agent from a 
list of people/agents by using a unique identifier (i.e. WebID). It the 
same as pointing a finger towards one person in a group. Another 
example: I should not be forced to perform authentication if I just want 
to "view" someone's FOAF card by dereferencing their WebID URI. However, 
authentication may be required in case some parts of the FOAF card are 
protected by access control policies.

Given the recent change in the definition of WebID (i.e. "A WebID is a 
hash HTTP URI which denotes an Agent. You can GET an RDF model as 
TURTLE."), I think it becomes clear how useful it is to separate the 
identity part from the authentication part, and being able to change the 
authentication protocol.

To conclude, I these three keywords as:

Identification -> (Authentication -> Authorization)

Andrei

On 10/31/2012 12:00 PM, Nathan wrote:
> 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 12:24:02 UTC