Subject: Re: Access Control deferred?

From: Doug Royer <[email-masked]>
Date: Fri, 8 Jan 1999 13:15:00 -0800 (PST)

> From: "Paul B. Hill" <[email-masked]>
> 
> Hi,
> 
> (parts cut out)
>
> I started writing this message before Doug Royer's posting to the list.
> Unfortunately a quick glance at Doug's posting convinced me that once
> again, requirements were skipped in preference to defining the specification.

The non-ietf-'wg' draft was discussed between several persons.
Had it been a ietf-wg draft - you would have seen the information.

> What disturbs me is that fact that every time I talk about access control
> with someone the conversation quickly turns to talking about things like
> the "difficulty in showing this attribute to that user, while hiding a
> different attribute from a third user." Were not there yet. During a
> breakout session at the LA meeting a small group concluded that CAP would
> _not_ address administrative requirements. However, I dont think anyone
> ever tried to enumerate what operations were considered to be
> administrative vs. functional requirements for an end user.  Im pretty
> sure that everyone at that breakout session would agree that migrating a
> user from one server to another would be an administrative task that would
> not be addressed by CAP.  But I am not sure that everyone at that breakout
> session would agree that creating a delegate would be addressed by CAP or
> not. 

As I recall in LA we said that the only administration that would be
in CAP was whatever the USER needed plus creating a new calendar for
them selves, and deleting a calendar they owned. I also think we
said that calendar store (vs calendar) administration would not be
in CAP.

I think that all other administration was considered not in CAP.

Creating a 'delegate' means different things to different implementations.
That's why I think the only way this will work is if we allow for
a grammar that will allow for finer control over access (attribute
hiding from the 3rd user).

One implementation may only have a 'make this person a delegate' button
on that implementations GUI. And the documentation and application
may mean that a named person can only 'accept' meeting for me.

Yet another implementation and application may need it to mean
that they can both 'create' meetings for me and 'accept' meetings.

I just don't think we can agree on what a 'delegate' means to
all current and future applications.

I also do not think that most CUA's will care what the ACL is on
another calendar. If you only look at interpersonal calendars
maybe you would care. However if the other calendar is vertical
application that implements some unique e-commerce scheduling activity,
the ACLs may be necessarily complex and not fall into a set of
predefined definitions. Yet I think there NEEDS to be a standard
way to define these complex ACLs.

I feel that there needs to be ACLs at the property level. Some
feel at the paramater level.

> However, this abstract does raise a point that the Calsched working group
> does need to consider. Does CAP require access  control operations to occur
> across autonomous security domains?
> 
> Would Steve Mansour at Netscape/AOL ever need to grant Frank Dawson of
> Lotus/IBM delegate rights to his calendar, _without_ creating a guest
> account for Frank within the Netscape/AOL security domain? Although I can
> think of situations where this would be desirable, I do not find this to be
> a requirement for purchasing an enterprise wide C&S system for my site.

I would think that ACL's would apply to authenticated users or
anonymous users. So if Steve Mansour at Netscape/AOL had an
account on Frank Dawson of Lotus/IBM calendar - YES.

E-Commerce web applications may use the users credit card number + the
users name as the authentication identity. Thus there could be
a need to exclude or include non local identities.

> What about fine granularity of read access across multiple security
> domains? E.g.  Is it a requirement that I can enable users from On
> Technologies and Crosswind to read my meeting descriptions but I can
> prevent people from AOL and IBM from doing so? Again, I dont find this to
> be a current requirement at my site.

There were strong requests for this - Sun included.

If the calendar were a rock concert - do you want ALL attendees
that were able to add themselves to the event to be able to
see the email addresses of all of the other attendees?

If you have a department meeting, I would think that it would
be nice of ALL attendees could see the email addresses of
all of the other attendees.

An event on the West coast - "Burning Ban". You can not see the
LOCATION until you have paid. In this example the 3rd person
can't see the LOCATION until they have paid and can never
see the other ATTENDEEs. The ORGANIZER however can always see
all properties in that VEVENT. There may be others that can
only see the ATTENDEES and LOCATION and never pay - for example
the land is administered by the US-BLM, they need to know how many
people are going to show up.

I see this kind of control as a MUST for e-commerce.

> Unlike the ACF draft this draft at least tries to tackle changing access
> control attributes instead of just querying them.
> 

(I'll respond to the LDAP part separately)

-Doug
-------------------------------------------------------------------
[email-masked]		http://www.royer.com/People/Doug
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 12 Jan 1999 08:34:29 -0500

List members:

Please welcome Pat Egen <[email-masked]> as the new co-chair for
Calsch.

Those that know Pat are aware of her extensive SHARE experience with
calendaring and scheduling.  In fact, Pat is SHARE's representative to Calsch.

Robert Moskowitz

---

From: "Paul B. Hill" <[email-masked]>
Date: Wed, 20 Jan 1999 17:03:45 -0500

Hi Doug,

>I think that all other administration was considered not in CAP.

OK, I think an assitant that is responsible for 20 meeting rooms, some
audio visual equipment, and is delegate for a couple of mid-level managers
is not a CS administrator and that CAP needs to accomodate the needs of
this user. I don't think that the current requirements draft will meet the
needs of this type of user.

Paul

---

From: "Paul B. Hill" <[email-masked]>
Date: Wed, 20 Jan 1999 17:07:41 -0500

>hiding from the 3rd user).

So are you saying that existing vendor implemenations are being used to
determine what can and cannot be addressed by the CAP requirements draft?

Paul