Re: identification, authorisation, authentication

On 10/31/12 8:23 AM, Andrei Sambra wrote:
> Following a conversation we had at TPAC, I personally see 
> identification as completely separate from authentication.

We have:

1. Identity
2. Identifiers
3. authentication
4. authorization .
>
> 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).

I would say that identification is the act of denoting something (e.g., 
an Agent) using an identifier. Basically, how an identity becomes 
identifiable.

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

The publisher of a document can use authentication to verify the 
identity of an Agent as part of an authorization workflow that 
constrains content access to a specific identity.
>
> 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.

Yes, but "A WebID is a hash HTTP URI which denotes an Agent. You can GET 
an RDF model as TURTLE." is an inappropriate and broken definition. At 
this point, the definition renders all the proxyURIs used by our systems 
as incompatible. All we did was implement URIs that conform with the 
principle of URI opacity plus the indirection heuristics of 5-star 
linked data.


>
> To conclude, I these three keywords as:
>
> Identification -> (Authentication -> Authorization)

identity->identifiers (function: identification) 
->authentication->authorization.

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


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen