RE: ACL Draft

> ----------
> From: 	hep@netscape.com[SMTP:hep@netscape.com]
> Sent: 	Thursday, October 23, 1997 8:18 PM
> To: 	Paul Leach
> Cc: 	w3c-dist-auth@w3.org; 'Larry Masinter'
> Subject: 	Re: ACL Draft
> 
> Paul,
> 
> > > As for user perception of the complexity of booleans: we're talking
> > > about the PROTOCOL here. Whether you let the user's see the booleans
> > > directly or have some kind of check-box interactive display is an
> > > interface issue.
> > >
> > If you can show me at least one UI design that hides this complexity,
> > I'll buy it. Until then, it will be true that I've never seen a UI that
> > can make anything simpler than the underlying intrinsic complexity --
> > it's the law of conservation of complexity.
> 
> I'll bet you've already bought it.
> 
Actually, I get it for free :-) 

Or perhaps it's more correct to say that they have to pay me to use it?
:-)))

>   Do you use Windows NT?  Have you looked
> at its API for access control (or did you design it)?  It seems quite
> complex to me, although I believe I understand the need for the
> complexity.
> The UI for setting access control on files seems reasonably intuitive,
> however, at least to me.  It appears that your UI designer chose not to
> expose all of the underlying functionality, and got a pretty good result.
> 
To the contrary. Our usability studies show that most users have a very hard
time with ACL editing. And the functionality that isn't exposed through the
UI in effect does not exist.

As to the API, there's a difference between complex/baroque encodings and
complex concepts. A baroque encoding 

> Another interesting thing about that API is the fact that it exposes
> security identifiers (SIDs) for users and groups.  Not entirely, but it
> provides quite a few functions for doing useful things with them.  When I
> login to NT, I enter my username as "hep".  I do not enter my SID.  Why is
> that?  And why don't the ACLs refer to me by my username when I retrieve
> them through the API?
> 
An API is not a protocol. A protocol meant for NT to NT isn't necessarily a
good protocol between heterogenous systems.

Or are you suggesting that I supply the WG with a spec for the on-the-wire
description of NT security descriptors and we adopt it for DAV? :-)))

> What I'm looking for in the access control protocol is something like the
> SID as a user id or group id.  It can be opaque, but it needs to have
> certain properties (as the SID does), and it would sure be nice if the
> protocol supported analogs of a lot of those nice functions that the NT
> API
> provides for SIDs.
> 
I deliberately left SIDs out, because they are OS specific. I thought of
doing exactly what you suggested, making them opaque,  but that would
require adding mechanisms to map from the opaque form to the interoperable
form. It seemed simpler to just use the interoperable form in the ACE, and I
saw no firm reason to do something more complicated, so that's what I did.

If we can come up with a good reason to change that decision, I'm happy to
reconsider.

> I imagine, although I don't know, that NT-to-NT authentication uses SIDs
> in
> the authentication credentials.
> 
Actually, it doesn't. It sends username and domain in ASCII.

>   If so, that's swell for you and your
> proprietary authentication protocol, but those of us who have to support
> authentication protocols such as HTTP basic authentication don't always
> get
> to choose what form the authentication credentials take.  That shouldn't
> mean that we have to do without something like SIDs in the access control
> protocol, since we can map the authentication credentials to whatever we
> like.
> 
SIDs on-the-wire are (an attempt at) an optimization that (might) make sense
in a homogenous distributed system, but that isn't appropriate in a
heterogenous one. In fact, it was really just lazy protocol design -- we bit
copy the ACL from the disk into the packet. And we regret it every time we
change the format of ACLs, and there are things that we haven't been able to
do as a result of being trapped by the legacy.

So, I don't think we should let "SID-envy" drive this protocol design.

Paul

Received on Friday, 24 October 1997 13:33:51 UTC