Subject: [Ace] Authorization on the client side

From: Stefanie Gerdes <[email-masked]>
Date: Wed, 04 Mar 2015 19:37:53 +0100

Hi all,

What I get from the discussion is that we agree that there is an 
authorization problem on the client side. We also agree that for some 
authorization problems we don't need a sophisticated authorization 
mechanism.

So maybe we can postpone further discussions about solutions and just 
finish the use cases draft?

We can keep the authorization problem on the client side in the problem 
summary sections. Moreover, we can add the following to section 3.2 
(Configuration of Access Permissions): "Endpoints need to be enabled to 
enforce the authorization policies of their principals. In some cases, 
authorization problems might bei solved by implicit authorization (all 
authenticated entities are authorized)."

What do you think?

Best regards
Steffi

-- 
Stefanie Gerdes			Tel: +49 421 218 63906
TZI Universität Bremen		E-Mail: [email-masked]
Bibliothekstr. 1, MZH 5150
28359 Bremen, Germany

---

From: Göran Selander <[email-masked]>
Date: Wed, 4 Mar 2015 19:07:29 +0000

Hi Steffi,

I disagree.  If you recall from
http://www.ietf.org/mail-archive/web/ace/current/msg00995.html
I listed a number of “authorization problems” on the client side, none of
which is of the concern of ACE IMHO. The same applies the problem you
list, corresponding to U1.2b of
http://www.ietf.org/mail-archive/web/ace/current/msg01019.html.

Just because I haven’t had time to answer this mail thread today doesn’t
mean that you can forget about our last months of discussions. I’ll be
back.

Best regards,
Göran

On 2015-03-04 19:37, "Stefanie Gerdes" <[email-masked]> wrote:

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

---

From: Stefanie Gerdes <[email-masked]>
Date: Thu, 05 Mar 2015 09:39:38 +0100

Hi Göran,

I didn't forget our discussion. But it would be helpful to summarize the 
things we agreed on. You said that you agree that there is an 
authorization problem on the client side. You also agree that we don't 
need a sophisticated authorization mechanism to solve every 
authorization problem.

In your e-mail, you listed additional authorization problems that are 
not part of the current discussion. I don't see how discussing these 
helps things.

Best regards,
Steffi

---

From: Göran Selander <[email-masked]>
Date: Fri, 6 Mar 2015 07:45:50 +0000

Hi Steffi,

I sympathise with trying to summarize.

I admit that I called requesting to open a lock “authorization”. A
momentary lapse of reason. This is a known risk when  working with proof
by contradiction. If you reflect on it, if every potential request or
action is interpreted as authorization, there is not much left that is not
authorization. So I take that back. I would not call deciding whether
requesting a lock to be opened to be an authorization problem.

The other examples I mentioned served the same purpose: they illustrate a
lot of things on the client side that analogously would be called
authorization, and for that reason should not be called authorization.

Best regards,
Göran