W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2007

Re: [ACL] Re: Find my principal resource

From: Wilfredo Sánchez Vega <wsanchez@wsanchez.net>
Date: Thu, 1 Feb 2007 16:21:55 -0800
Cc: Cyrus Daboo <cyrus@daboo.name>, "'acl@webdav.org'" <acl@webdav.org>, WebDAV <w3c-dist-auth@w3.org>
Message-Id: <48FE21A9-690E-49CA-8DB5-8086B5471CAB@wsanchez.net>
To: Julian Reschke <julian.reschke@gmx.de>

On Jan 31, 2007, at 10:55 AM, Julian Reschke wrote:

> Cyrus Daboo schrieb:
>> The problem with that is that it not only returns the current  
>> user's principal, but any group principal that one is a member of.  
>> So how would you know from those which was the actual user  
>> principal? i.e. this approach is not 100% reliable.
> Well, you can easily filter out groups, but in the end you may still  
> end up with more than one resource.

   Filtering out groups is not correct.  Nothing says that a user's  
principal can't also be a group; a user can have members.

>> If there really isn't a way to reliably do this now, I would  
>> propose the following: define a new DAV:self-principal-resource (or  
>> just DAV:self) property that is available on any resource  
>> supporting ACL and which contains a single DAV:href pointing to the  
>> principal resource for the currently authorized user (or is empty  
>> if anonymous).
> I think the spec would have defined exactly that would there have  
> been a consensus that this kind of definition always is meaningful.

   So would it be reasonable to define this in an extention where we  
can define it meaningfully?

   Some background:

   In the context of CalDAV, some of us are considering the value of  
having one URL you can give to any user with which a CalDAV client can  
be configured to find your calendar server and take it from there.

   This requires that at least one (ideally any) CalDAV resource on  
the server be able to tell the connecting user where their principal  
resource is.  The reason for that it that the principal has some  
important information that a client needs to bootstrap itself.  In  
particular, it defined a property which tells the client where the  
user's home collection is, and another listing the valid calendar user  
addresses (needed to know who "I" am in the context of iTIP messages).

   What we are doing at Apple right now is we give each user the URL  
to their principal.  This is no big deal if you can rely on a  
directory system to find that, but even then, it's a bit of an  
administrative bother.  We're defining a string template from which  
you can compute this URL from other data about the user in the  
directory (eg. username).  It's putting the directory in a position of  
needing to know something about the URL schema of the calendar server.

   Much easier would be to give all users the same URL (eg. the root  
resource) and give the client a way to locate the principal themselves.

Received on Friday, 2 February 2007 00:22:25 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:36 UTC