Subject: [Ace] Unique resource identifiers

From: Ludwig Seitz <[email-masked]>
Date: Wed, 21 Jan 2015 15:06:01 +0100

Hello,

I'm just (re-)thinking the issue of authorization tokens and how to
encode authorization decisions, and the following problem has come up:

We need to uniquely identify a resource in order to do any kind of
non-local authorization on it.

At first the obvious approach seemed to be to use Uri-host and Uri-path
of the origin server, but there are several problems with this:

1.) The origin server might change address, see e.g.
http://www.ietf.org/mail-archive/web/core/current/msg05625.html

2.) The resource might not be on the origin server when access control
has to be performed, say e.g. a store-and-forward scenario, or a
publish-subscribe scenario as in
http://tools.ietf.org/html/draft-koster-core-coapmq-00.

I think we might need some unique resource identifier that is neither
dependent on the host address nor on the internal resource hierarchies
on the origin server.

The added benefit would be that a proxy could handle encrypted
resource representations, without gaining any knowledge about the
internal resource structure on the origin server.

What do you think about this issue?

Regards,

Ludwig Seitz

PS: Sorry for cross-posting this to CoRE, but I suspect we might get
some useful input from there.

-- 
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: "Kepeng Li" <[email-masked]>
Date: Wed, 21 Jan 2015 22:22:54 +0800

One possible way is to use EndpointID to identify the origin server,
instead of using Uri-host.

EndpointID should be unique within one Resource Directory domain.

It works in case of IP address change, and store-and-forward scenario, or
publish-subscribe scenario.

This may add burden to the Authorization Server to correlate EndpointIDs
and Uri-hosts.

Kind Regards
Kepeng

在 21/1/15 10:06 pm， "Ludwig Seitz" <[email-masked]> 写入:

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

---

From: "Derek Atkins" <[email-masked]>
Date: Wed, 21 Jan 2015 09:27:22 -0500

Sounds like you are trying to re-invent HIP.  (See RFC 5201 and RFC 4423)

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Ludwig Seitz <[email-masked]>
Date: Thu, 22 Jan 2015 10:04:10 +0100

> Sounds like you are trying to re-invent HIP.  (See RFC 5201 and RFC 4423)
Thank you Derek, but I'm actually not so much interested in the host 
identity, what I need in order to do access control is a stable resource 
identifier. It seems to me that in certain cases Uri-host + Uri-path 
isn't as stable as one would like.

So perhaps it would be useful to first discuss if we agree that there is 
a problem. If so, we can start looking if there already is a solution or 
if we need to find one ourselves.

/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: Olaf Bergmann <[email-masked]>
Date: Thu, 22 Jan 2015 12:14:43 +0100

Ludwig Seitz <[email-masked]> writes:

> identity, what I need in order to do access control is a stable
> resource identifier. It seems to me that in certain cases Uri-host +
> Uri-path isn't as stable as one would like.

The path components of URIs should be stable in the REST world,
don't they? Isn't this an important aspect of URIs. [0]

However, if you really feel addressing content objects "on the wire",
you should have a look into the ICN work going on the IRTF, but I think
this is not on the short-term agenda for ACE, right?

[0] http://www.w3.org/Provider/Style/URI.html

Grüße
Olaf