Re: [Ace] Terminology (again)

[Eve Maler <[e-mail]>]

Hi folks— Yes, UMA has used OAuth-aligned terminology for some time now. BTW, the final V!.0 UMA specs are here:

https://docs.kantarainitiative.org/uma/rec-uma-core-v1_0.html
https://docs.kantarainitiative.org/uma/rec-oauth-resource-reg-v1_0.html

And there are even draft versions of patch releases out for review:

https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1.html
https://docs.kantarainitiative.org/uma/draft-oauth-resource-reg-v1_0_1.html

(I’ll see about a more rationalized way of doing Kantara spec links/publications to ensure that mentions of the V1.0 draft get you to the latest version somehow.)

Today I happened to publish a diagram that may help in understanding the relationship between UMA and OAuth role terminology. This has come up in previous ACE discussions as well, so it seems to make sense to link it here too:

https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/DEfEjoBfFxs

In UMA, the user of the client (what UMA calls the requesting party) typically has to undergo a process of trust elevation, which requires that they authenticate to and/or present claims to the AS (same AS as the resource owner's) in order to get authorization to access the protected resource.

	Eve

> On 30 Sep 2015, at 6:57 AM, Paul Madsen <[e-mail]> wrote:
> 
> 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
> 
> _______________________________________________
> Ace mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace


Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: [e-mail]