Re: identification, authorisation, authentication

Kingsley, Nathan,

Thanks for the clarifications. I'll adopt Kingsley's breakdown for my
PeerPoint project:

1. Identity
> 2. Identifiers
> 3. authentication
> 4. authorization .
>
> identity->identifiers (function: identification)
> ->authentication->authorization
>

And from Nathan:

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.
>
> Identity is separate from Authentication as you say, but an
> authenticated-agent-identifier is the product of authentication.
>
> 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.
>


Makes sense to me. I have really been wrestling with how to organize and
relate all these concepts/steps for the PeerPoint p2p application
requirements and your feedback has cleared it up nicely. Thanks again!

I may have questions when I get into the implementation side of it. Can you
point me to one or two of the best overview docs on p2p authentication
methods so I won't be asking dumb questions???

Regards,

PR


On Wed, Oct 31, 2012 at 8:09 AM, Kingsley Idehen <kidehen@openlinksw.com>wrote:

> 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<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<http://www.openlinksw.com/blog/%7Ekidehen>
> Twitter/Identi.ca handle: @kidehen
> Google+ Profile: https://plus.google.com/**112399767740508618350/about<https://plus.google.com/112399767740508618350/about>
> LinkedIn Profile: http://www.linkedin.com/in/**kidehen<http://www.linkedin.com/in/kidehen>
>
>
>
>
>
>


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

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