From: "Tyler Close" <tyler@...>
>
> Does this mean that you are dropping authorization methods 2 and
> 5, from Michael Day's list of 5 authorization methods?

Nope. See below.

> Does this mean that you are rescinding your opinion that:
> "Generating URLs containing authentication tokens seems like a Bad
> Idea"?

Nope. See below.

> Taking this step raises a question about another part of the RNA
> design. If the resource identifier and the authority to access the
> resource are always transferred as a single unit, why does RNA
> contain a mechanism to authenticate the source of a notification?
> What attack does this authentication mechanism defeat?

Simple impersonation. For instance, you may have an address like
http://rnaserv.com/close/tyler. I may have a higher trust in notifications
that come from that address. However, since a notification is pushed, it
could come from *anywhere*. So, it would be possible for someone other than
yourself to send me a notfication that indicates you as the sender. Or,
someone could just as easily give a totally ficticious address.

Now, I have to admit that I am not very fond of the query mechanism. There
are certainly more elegant ways of solving the problem, but I felt it was
important to provide a simple version within the specification. This means
that, even if a more elegant solution is layered on top (e.g. PKI
signatures), if a particular client cannot take advantage of the solution,
it can still "fall back" to the query mechanism.

As always, if there is a way that capabilities can make queries unnecessary,
I am all ears.

> > Also, the reason I suggest using user/pwd instead of a random,
unguessable
> > token in the URI is because I think the user/pwd is more in line with
the
> > REST philosophy.
>
> Please explain.
>
> > This ensures that a single uri (sans the "user:pwd@
> > part") identifies the same representation of the resource regardless of
> > which authentication credentials are provided, which is important for
> > things like caching proxies, etc...
>
> But given the decisions you've made above, the same authentication
> credentials are always provided. If you start mixing and matching
> authentication credentials and URLs, then you once again open
> yourself up to a Confused Deputy attack.
>
> A cache is perfectly happy with a URL that contains a secret in
> the path.

But it is not the place of RNA to dictate how a particular server is
implemented. As a result, a server may choose to use a single URI for all
recipients of a given resource. In this case, it would make little
difference between using a "user/pwd" or a nonce in the URI. However, a
server may want to issue a separate capability URI to each recipient of the
same resource. In this case, I would recommend using multiple "user/pwd"
pairs instead of multiple nonces in the URI, again for the purpose of
efficient caching, etc.


> > As I understand it, the sender has a resource he want's to make
available
> > to a recipient. The sender assigns a capability (URI + user/pwd, in
this
> > case) and gives it to the recipient. Now, maybe I am not understanding
the
> > subtleties of a "capability URI". If I have got it wrong, can you given
an
> > example (possibly in context of RNA) that would make the difference more
> > clear?
>
> Assuming you mean a unique "user/pwd" for each resource, and that
> the combined URI is passed using a secure communications channel,
> then the URI is a "capability URI".

Suppose you were to send a capability URI to two recipients. How would you
revoke the capability for just one recipient? It seems to me you would have
to revoke the first capability, then re-issue a new capability to the single
recipient. Otherwise, the only other approach I see would be to generate
two capability URIs to start with...

>
> I think the only subtlety you are missing is that there is no
> advantage to using a "user/pwd" instead of a nonce in the URI
> path. On the other hand there are disadvantages to using HTTP
> Auth. You are doubling your network round trips, for no useful
> purpose.

Yes, I agree that there is additional overhead using HTTP Auth. If your
server were implemented such that a single capability were generated
regardless of the number of people accessing the resource (recipients), then
using the nonce may be a more efficient way to go...

---
Seairth Jacobs
seairth@...