Re: [Ace] Terminology (again)

[Paul Madsen <[e-mail]>]

On the call I asserted that UMA used AM for 'Authorization Manager'

In looking at the UMA spec 
[https://docs.kantarainitiative.org/uma/draft-uma-core.html], it seems I 
was wrong.

I do believe earlier versions of UMA did define 'AM' but presumably they 
subsequently decided to deprecate in favour of AS (and so stay 
consistent with OAuth)

Regards

Paul

On 9/30/15 6:59 AM, Stefanie Gerdes wrote:
> 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
>
> _______________________________________________
> Ace mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace