Re: identification, authorisation, authentication

Hi Andrei,

Perhaps this is better termed generally as an 
"authenticated-agent-identifier", within the context of auth* - and an 
"agent-identifier" when it hasn't been authenticated/verified.

Or within the context of WebID-Protocol, a "WebID" (hash HTTP URI which 
denotes an Agent. Where you can GET an RDF model as TURTLE.) and an 
"Authenticated WebID" (one which has been verified/authenticated with 
WebID Protocol for WebID Authentication).

Identity is separate from Authentication as you say, but an 
authenticated-agent-identifier is the product of authentication.

Thus generally we have:

1) agent-identifier (a URI which denotes an agent)
2) authenticated-agent-identifier = Authentication->authentice(*)

Or using our common webid-*,

1) WebID (a hash HTTP URI which denotes an agent, for which you can get 
an RDF model describing the agent as TURTLE)
2) Authenticated-WebID (a WebID which has been authenticated using 
WebID-Protocol)

Does that clarify / make sense?

Best,

Nathan

Andrei Sambra wrote:
> 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 13:18:38 UTC