Re: [Ace] Terminology (again)

[Stefanie Gerdes <[e-mail]>]

Hi Ludwig,

On 09/30/2015 11:09 AM, Ludwig Seitz wrote:
> On 2015-09-30 10:20, Carsten Bormann wrote:
>> (Pulling the discussion out of a private exchange to the mailing list.)
>>
>>> I don’t think it is about the definitions not being clear. It is just
>>> the
>>> names of the nodes, where in the current draft 5 out of 6 terms are
>>> imported from the analogous setting in OAuth/UMA and the 6th, CAS, is
>>> coined by Carsten.
>>
>> The definitions in the current WG Actors draft are clear enough for me.
>> They are just using terms that mean something different in OAuth.
>>
>> RFC 6749 says:
>>
>>     authorization server
>>        The server issuing access tokens to the client after successfully
>>        authenticating the resource owner and obtaining authorization.
>>
>> Nope, that's not at all the AS in the Actors draft.
>>
> 
> I believe you are making an academic distinction here. Of course there
> are differences between how the AS is used in OAuth and how the
> different proposals use it in ACE, but the similarities are still quite
> striking.
> 
> 1. The ACE AS issues access tokens to the client (via the CAS if there
> is one).
> 
> 2. The ACE AS at some point in time will authenticate the resource
> owner, when he/she configures the authorization policies that govern how
> authorization for that resource can be obtained.
> 
> How is that fundamentally different from the OAuth AS?

First of all, we have an authorization manager, i.e. a less-constrained
device, that is responsible for the client (what is called CAS in the
terminology). That is different from the OAuth model where there is no
such actor. If we cling to the OAuth terminology, we are not even
allowed to call the Server's authorization manager SAS. It is called AS.
That makes things very awkward and incomprehensible.

The constrained devices are not capable of managing complex
authentication and authorization tasks on their own. They need their
authorization managers for that. Owners will not necessarily be present
at the time of access. Therefore, the authorization managers will need
to represent the owner, manage their authorization policies and security
associations, and generate simplified authentication and authorization
information that the constrained devices can digest. AMs therefore are
the link between the constrained and the less constrained world.

I think this is different from what an OAuth authorization server does
(We don't call a cow a sheep only because it also has four legs).
Authorization Managers can be integrated with OAuth Authorization
Servers. An example for that can be found in
draft-gerdes-ace-dcaf-examples [1].

> 
> Also OAuth has usecases where the AS is used in a way that is even more
> similar to the ACE proposals (cf. the client credentials grant).
> 
>> I have not yet heard a convincing reason why appropriating terms from a
>> different domain is helping us here.  What does this do?
>>
>> 1 -- People coming from the OAuth world will feel at home immediately.
>> But that is a treacherous comfort: They'll expect things to be the same
>> in the IoT world.  They aren't.**)  IoT authorization is almost, but not
>> entirely, unlike Browser Web authorization.
> 
> I think you underestimate the OAuth people. I am sure those
> participating in the ACE work are well aware that there are significant
> differences (but also overlaps).
> 
>> 2 -- People coming from the IoT world first have to learn the OAuth
>> terminology.  I teach this stuff, and I can tell you, that terminology
>> is suboptimal for learners.  When they are done with this, see 1.
> 
> They will have to learn some authorization terminology, so why not use
> an existing one instead of making up yet another?
> 
>> Choosing terms that are adapted to what we are actually trying to do has
>> none of these problems, and it also allows to choose terms that are easy
>> to remember and have the right connotations***).
> 
> Instead we have the much bigger problem that we force people to learn
> yet another set of (totally new) terminology which will lead to even
> more confusion when the web world needs to interact with the IoT world
> and the terminology is not aligned.

I'd rather have people learn a new terminology and really understand
what it means. As we have seen, people are already confused by the
CAS-AS-RqP-RO-Terminology. This is the chance to use a terminology that
is easier to digest.

Best regards,
Steffi

[1] https://tools.ietf.org/pdf/draft-gerdes-ace-dcaf-examples-00.pdf