Subject: [Simple] XCAP Auth: to which resource does a permission apply

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 10 Jul 2004 07:25:58 -0400

Folks,

I posted an open issue on the list some weeks back around the resource 
lists. It had suggested that we split the resource-list document into 
two parts. One part is a pure list, independent of any particular usage 
(ie.. subscribing to it for a buddy list), and a separate part, which 
defines the URIs that I can actually subscribe to for accessing a buddy 
list. You can take a look at that note here:

http://www1.ietf.org/mail-archive/web/simple/current/msg03259.html

There were generally supportive comments on this proposal, so I went 
ahead and made the update to the document. I'll first say that it is a 
vast improvement; not just because it adds some efficiency, but because 
the notion of a resource list truly is fundamentally separate from a SIP 
service (such as a subscribeable buddy list) which uses that resource 
list. Separating them clarified the document and makes for an overall 
much more generic and useful solution.

While making this change, I began to consider how we would support 
permissions for subscribing to a resource list. In other words, if I 
have a group buddy list, like [email-masked], and I want anyone 
in marketing to be able to subscribe to it, how would I set up the 
permissions for that? The answer is really obvious - we already have a 
solution. The presence authorization rules spec can be used to define 
permissions to subscribing to any presence resource; and that would 
include a list. As such, out of the box, that document can be used to 
define permissions for a list.

That introduces a problem, which is how one goes about defining which 
permissions to apply when the server gets a subscription to a particular 
buddy list. Right now, the document says that the server fetches all of 
the permission documents associated with that user. That won't work if 
those permission documents can be applied to subscriptions to a 
multiplicity of resources. That will be the case if we want to use those 
permissions for buddy list resources. It will also be a problem if a 
single user has a multiplicity of aliases for which it wants the same 
permissions to apply.

There are two possible ways to fix this:

1. You pretty much do the same kind of thing that the referenced email 
describes for resource lists. You need a separate index, which says, for 
each resource on a server, what are thet set of permission documents 
that get applied when you receive a subscription for that resource. This 
index is writeable by a user, and it can only contain resources that are 
"owned" by that user.

2. You can add a new condition to the rule document, which specifies the 
target resource as part of the condition of applicability.

The drawback of just doing (2) is that, when a server gets a 
subscription for a list resource, it has to do use the xcap directory, 
get tons and tons of documents, and then determine which ones apply. 
Most won't.

If (1) is done, the buddy list server can figure out, with a single XCAP 
query, the entire set of premission documents it has to fetch in order 
to process the request. I think thats really important as a property. 
Indeed, it is this property which drove me to suggest the approach in 
the email above for resource list definitions themselves.

The drawback of doing (1) alone is that rule documents start to lose 
their meaning as standalone permissions, and I'd like them to be 
meaningful outside of xcap.

So, my proposal is to do (1) and (2).

I think its important to note that this problem, and the problem 
documented in the above referenced email, are closely related to the 
recent XCAP directory proposal by Miguel. In particular, Miguels 
document allows for reading of a directory, which is effectively an 
index of documents. However, the directory solution does NOT work for 
this problem; the reason is that the user has to explicitly WRITE the 
index - that is, it has to explicitly say which permission documents are 
to be applied to a subscription for a particular resource, and it has to 
explicitly say which resource list is associated with a buddy list URI.

Thus, I believe if we proceed with doing (1) and (2), the directory 
approach becomes a nice-to-have, but won't be essential at all for 
making resource-lists or presence authorization rules work. The reason 
is that the index documents exist in a fixed location. As such, when a 
client starts up, and it has no idea about anything, it can fetch the 
index lists, and those index lists contain references to the resource 
lists/rule documents for that user. Thus, they ALSO serve as a directory 
function. It is possible that a user has defined permissions or resource 
lists that are not bound to an index. In that case, a cold-start client 
would not know about them. In such a case the XCAP directory would be 
useful. However, if a client simply doesnt do that; that is, if a client 
only ever defines resource lists that it uses, and rule documents that 
it uses, you won't ever need the directory.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple