Re: identification, authorisation, authentication

On 1 November 2012 00:26, Poor Richard <poor.ricardo@gmail.com> wrote:

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

It's not a dumb question at all, I'd be interested to see a summary of
authentication techniques too.

A few things to point out.

1. Many systems in the real world thrive without authentication. Emial /
The Postal Service / Telephone are examples.
2. Yet authentication can be added where necessary
3. Sometimes authentication is not needed
4. Sometimes authentication is not appropriate

Some authentication and security techniques I can think of

- Security by obscurity
- Shared secrets
- Unguessable strings
- Bearer tokens
- PKI
- Delegated credentials
- Signing
- Mirrored claims
- DNS based
- Username / Password
- Cookie

http://en.wikipedia.org/wiki/Authentication

Sorry, the above list is slightly vague.  But the point is that when you
couple identity to authentication, you solve a problem, but at the loss of
a great deal of modularity.


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