Subject: Re: [Ace] Terminology (again)

From: Carsten Bormann <[email-masked]>
Date: Wed, 30 Sep 2015 10:20:54 +0200

(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 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.

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.

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

Also, where OAuth is then actually being employed at the
less-constrained level, it leaves the OAuth terms free for the OAuth
roles (which may be allocated quite differently), and does not cause
confusion with the ACE roles.

Grüße, Carsten

**) I remember the fun period when SIP was forking off from HTTP, and
(not only) the HTTP people had all those misconceptions for what SIP
would do, just because HTTP did it as well.

***) If you don't like the original Actors terms: We still can change
those.  But we first have to unshackle ourselves from the OAuth terms.

---

From: Erik Wahlström neXus <[email-masked]>
Date: Wed, 30 Sep 2015 08:32:44 +0000

Hi Carsten,

See below.

> On 30 Sep 2015, at 10:20, Carsten Bormann <[email-masked]> wrote:
> 

Different domain? It’s a continuum between constrained and non-constrained devices. It’s also methodologies used in existing IAM infrastructures. And those are the exact same infrastructures that will need to support constrained devices.

> entirely, unlike Browser Web authorization.

Concepts are the same. It’s just some profiling that’s needed to oauth and the people coming from oauth world is used to that (opened connect and so forth). 

> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

---

From: Stefanie Gerdes <[email-masked]>
Date: Wed, 30 Sep 2015 10:45:16 +0200

Hi Erik,

Comments inline.

> Different domain? It’s a continuum between constrained and non-constrained devices. It’s also methodologies used in existing IAM infrastructures. And those are the exact same infrastructures that w…

Sure, we need constrained and less-constrained devices to talk to each
other. What Carsten meant is that the characteristics of constrained
devices and constrained environments are special. The less-constrained
device that is responsible for the constrained device needs to perform
specific tasks that the device cannot perform itself. That is different
from the web world, where devices are capable of performing these tasks
on their own.

> Concepts are the same. It’s just some profiling that’s needed to oauth and the people coming from oauth world is used to that (opened connect and so forth). 

When we are using OAuth in the constrained world we will also need to
consider the constrainedness of the devices.

Best regards,
Steffi

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 30 Sep 2015 10:45:32 +0200

> Concepts are the same. It’s just some profiling that’s needed to oauth and the people coming from oauth world is used to that (opened connect and so forth). 

Hammer/Nail.

I understand that there are solutions being proposed that take this
approach, and I'm not opposed to having some of those solutions in the
ACE toolkit, as long as we also do solutions for the domains I'm
interested in.

However, I'm not sure it is wise to shape the terminology to account
just for this subset of the solutions.

Grüße, Carsten

---

From: Ludwig Seitz <[email-masked]>
Date: Wed, 30 Sep 2015 11:09:14 +0200

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

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

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

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

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

We don't want to create a silo of IoT authorization terminology do we?

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 30 Sep 2015 11:21:54 +0200

> How is that fundamentally different from the OAuth AS?

They are not if you squint a lot.

> differences (but also overlaps).

I'm not always so sure about the level of awareness here.
But, more importantly, we are not writing our documents so that just the
elite IETFers can make use of them.

> an existing one instead of making up yet another?

I thought I answered that right above.

(And it's not like the Actors draft has whole-sale made up new
terminology; it still uses C and RS, and ROP vs. RO could be harmonized
again without too much of a loss; that change was just a reaction to the
observation that the term "owner" is misleading.  Only where more
differentiation is needed, is it worth to make specific terms.)

> and the terminology is not aligned.

As long as you think the OAuth terms actually fit the actors, you can
make this argument.  But that also just serves to underline my argument
number 1; you are letting those terms guide you to not take note of the
differences.

> We don't want to create a silo of IoT authorization terminology do we?

I don't think a couple of better terms will silo ACE.

Grüße, Carsten

---

From: Stefanie Gerdes <[email-masked]>
Date: Wed, 30 Sep 2015 12:59:26 +0200

Hi Ludwig,

> 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].

> 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

---

From: Paul Madsen <[email-masked]>
Date: Wed, 30 Sep 2015 09:57:38 -0400

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

---

From: Eve Maler <[email-masked]>
Date: Wed, 30 Sep 2015 11:47:01 -0700

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 <[email-masked]> wrote:
> 
> 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
> 

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