Subject: ACL idea

From: Doug Royer <[email-masked]>
Date: Tue, 15 Dec 1998 21:37:57 -0800 (PST)

Frank an I are tossing this out knowing that it is not done.  As Frank
has put in the past - its half baked. The ACL grammar has holes and we
know that it is going to take a LOT more thought.

The sooner others start to provide feedback as to the editors, the
sooner a CAP draft can be produced.  Does this look on track - or will
we be wasting our time if we pursue plugging the holes in the grammar?

The idea here is to start prompting discussion and ideas.

THANKS!
-Doug

	P.S. - I am going on vacation starting tomorrow.
	I will not be reading any email until I get back - Jan 4th.

Happy Holidays!

-------------------------------------------------------------------
[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

Calendaring and Scheduling Working Group          Frank Dawson/Lotus
Pre-Draft-Ideas                          Doug Royer/Sun Microsystems
<draft-???.txt>
Expires six months after:               <tbd>

                   CAP Access Control Rights Proposal

  NOTE: This information is provided to promote feedback. This is
  not yet an internet draft. With the recent discussions about CAP
  and ACLs, Frank and I thought we would send this pre-draft so that
  others could see our thoughts. The ABNF may not be correct and there
  may be other errors, feedback welcome.

  Please feel free to submit alternate proposals for consideration
  by the WG for inclusion in CAP-00.

1.  Abstract

This is a proposal for a CAP access control list capability.  The propo-
sal involves adding a "ACLRIGHTS" value type, "RIGHTS", and "ACLID" com-
ponent property and an "VACL" calendar component to iCalendar.

When any access control rights are in effect, all rights are denied
unless specificly granted.

RIGHTS are processed in the order provided.  That is if RIGHTS are
GRANTed to all users by default, then later a RIGHTS property may REVOKE
the rights for specific users.

2.  Capability

Any transport or protocol that needed to use this proposal would need to
send a capability command and the reply would contain at least a
"CALACL" capability.

If the CS does not return a "CALACL" capability, then the CS does not
support a CUA setting, getting, deleting, or modifying these ACLs.  The
CS may have other out of band ways of performing these operations.  Its
just that they are not available to a CUA.  An example of this is a
sporting event calendar.  A baseball team calendar might not give away
any ACL information.  A specific CS implementation might never need to
implement CALSCH-ACLs.  The administration of the baseball schedule may
just be someone editing a file on a server that contains the schedule.

Dawson/Royer               Expires: June 1999           FORMFEED[Page 1]

Pre-Draft-Ideas              iCalendar ACL             December 13, 1998

3.  ACLRIGHTS Value Type

Value Name: ACLRIGHTS

Purpose: This value type is used to identify properties that contain an
access control rights specification.

Formal Definition: The value type is defined by the following notation:

aclrights       = [caluser ";"] (aclref / acldef)

caluser         = "CALUSER" "=" ('"' text '"' / all / "OWNER" / "NONOWNER")
                  ; The "text" value above specifies an authenticated
                  ; calendar user

aclref          = "ACLID" "=" acl-id-text *("," acl-id-text) CRLF

acl-id-text     = <Must name an existing ACLID in the store or calendar>

acldef          = action (object / policy) CRLF

action          = access "=" act-type *("," act-type)

access          = ( "GRANT" / "REVOKE" )

act-type        = ("CREATE" / "MODIFY" / "DELETE" / "READ")

object          = ";" "OBJECT" "=" (csprop *("," csprop))
                                / (calprop *("," calprop))
                                / (component *("," component)) [cvalue]
                                / (compprop *("," compprop))
                                / compparam value
                                / "RIGHTS"

policy          = "POLICY" "=" iana-text / x-name

all             =  "ALL"

csprop          = all / csprop2

csprop2         = <any calendar store property defined in [CAP] and any
                  other IANA registered calendar store properties>

calprop         = all / calprop2

calprop2        = <any calendar property name defined in [ICAL] and [CAP] and
                  any other IANA registered calendar properties>

Dawson/Royer               Expires: June 1999           FORMFEED[Page 2]

Pre-Draft-Ideas              iCalendar ACL             December 13, 1998

component       = all / component2

component2      = <any calendar component defined in [ICAL] and any other
                  IANA registered components>

compprop        = all / compprop2

compprop2       = <any component property name defined in [ICAL] and any
                  other IANA registered components properties>

compparam       = all / compparam2

compparam2      = <any component parameter named defined in [ICAL] and any
                  other IANA registered component parameter>

cvalue          = ";" "VALUE" "=" (all / 1*component-type)

component-type  = <any [ICAL] and any other IANA registered components>

value           = ";" "VALUE" "=" (all / paramvalue)

paramvalue      = <any value appropriate for the named parameter object>

Description: The value type is a structured value consisting of a list
of one or more access control rights rule parts.  Each rule part is
defined by a NAME=VALUE pair.  The rule parts are separated from each
other by the SEMICOLON character (US-ASCII decimal 59).  The rule parts
are not ordered in any particular sequence, unless noted in the ABNF.

The CALUSER rule part identifies the calendar user authenticated to the
calendar store.  If CALUSER is omitted then the ACLRIGHTS rule applies
to all users.

The ACLID rule part contains the identifier for a "VACL" calendar com-
ponent.  This identifier is matched to the ACLID property within the
"VACL" calendar component.

The action rule part defines how the rights can be granted with "GRANT"
or revoked with "REVOKE".

The valid values for the act-type are CREATE, MODIFY, DELETE, READ.
Multiple action enumerations can be specified as a COMMA character (US-
ASCII decimal 44) separated list of action enumerated values.

The OBJECT rule part defines the calendar store property, calendar

Dawson/Royer               Expires: June 1999           FORMFEED[Page 3]

Pre-Draft-Ideas              iCalendar ACL             December 13, 1998

property, and component property, that the action is restricted to.
Multiple OBJECT enumerations can be specified as a COMMA character (US-
ASCII decimal 44) separated list of OBJECT enumerated values.

The calendar access "POLICY" is a named set of calendar access seman-
tics; such as "busy time access". The definition of the policy specifies
which of the "action" enumerations are valid. It also defines the seman-
tics of the policy.  This is very useful for "object" definitions which
are not easily defined using an "object" specification.

Example: The following is a rule which specifies access rights for "foo"
calendar user to read the DTSTART and DTEND time values.

CALUSER="foo";GRANT=READ;OBJECT=DTSTART,DTEND

4.  VACL Calendar Component

Component Name: "VACL"

Purpose: Provide a grouping of access control rights.

Format Definition: A "VACL" calendar component is defined by the follow-
ing notation:

aclc            = "BEGIN" ":" "VACL" CRLF
                  aclprop
                  "END" ":" "VACL" CRLF

aclprop         = aclid aclrights *(aclrights)

Description: A "VACL" calendar component is a grouping of component pro-
perties that describe an access control list.

The "ACLRIGHTS" property defines for one or more authenticated calendar
user their access rights.

The "ACLID" property defines the local identifier for the "VACL" calen-
dar component.  Exactly one "ACLID" MUST be in a "VACL" component.  The
value of this property is matched to a reference to a "VACL" calendar
component in a "ACLRIGHTS" value type.

Granting specific access to a calendar store implies access to the
calendars in that calendar store using the same GRANT rights.  Revoking

Dawson/Royer               Expires: June 1999           FORMFEED[Page 4]

Pre-Draft-Ideas              iCalendar ACL             December 13, 1998

specific access to a calendar store implies revoked access to the calen-
dars in that calendar store using the same REVOKE rules.  Granting
specific access to a calendar implies access to the components in that
calendar using the same GRANT rights.  Revoking specific access to a
calendar implies revoked access to the components in that calendar using
the same REVOKE rules.  When a component contains an ACLID, it overrides
any calendar and calendar store RIGHTS.

Example: The following is an example of the "VACL" calendar component.
In this example user "guest" has read access to the "DTSTART" and
"DTEND" calendar components.  No other access is implied.

BEGIN:VACL
ACLID:"VIEW START AND END TIMES"
RIGHTS:CALUSER="guest";GRANT=READ;OBJECT=DTSTART,DTEND
END:VACL

In this example all users (no quotes around ALL) are given read access
to "DTSTART" and "DTEND".

BEGIN:VACL
ACLID:"VIEW START AND END TIMES (2)"
RIGHTS:CALUSER=ALL;GRANT=READ;OBJECT=DTSTART,DTEND
END:VACL

This example shows one way to allow all users to only view CLASS=PUBLIC
components.

BEGIN:VACL
ACLID:"VIEW START AND END TIME(3)"
RIGHTS:CALUSER=ALL;GRANT=READ;OBJECT=DTSTART,DTEND
RIGHTS:CALUSER=ALL;REVOKE=READ:OBJECT=CLASS;PRIVATE,CONFIDENTIAL
END:VACL

Here READ and MODIFY access is given to all users for PUBLIC entries.

BEGIN:VACL
ACLID:"READ and MODIFY PUBLIC entries"
RIGHTS:CALUSER=ALL;GRANT=READ,MODIFY;OBJECT=ALL
RIGHTS:CALUSER=ALL;REVOKE=READ,MODIFY:OBJECT=CLASS;PRIVATE,CONFIDENTIAL
END:VACL

This example allows all users to only see free/busy time.

BEGIN:VACL
ACLID:"View VFREEBUSY only"
RIGHTS:CALUSER=ALL;GRANT=READ;OBJECT=VFREEBUSY
END:VACL

Dawson/Royer               Expires: June 1999           FORMFEED[Page 5]

Pre-Draft-Ideas              iCalendar ACL             December 13, 1998

The calendar administrator could choose to not allow users to modify or
read the ACLs by storing this example as a calendar store VACL.  If they
perform an operation that is prohibited as defined by any VACL the
calendar administrator has defined, they get permission denied without
knowing why.  Only calendar and component owners (OWNER) can perform all
non-ACL operations by default on a calendar.

BEGIN:VACL
ACLID:"No user defined ACLs"
RIGHTS:CALUSER=OWNER;GRANT=READ,WRITE,MODIFY,CREATE;OBJECTS=ALL
RIGHTS:CALUSER=ALL;REVOKE=ALL;OBJECT=RIGHTS,VACL,ACLID
RIGHTS:CALUSER="cal-admin";GRANT=ALL;OBJECT=RIGHTS,VACL,ACLID
END:VACL

Or perhaps an implementation would hard code into the CS or configure at
start up time a rule like this in order to properly implement a legacy
interface.  Here all ACLs are disabled for everyone:
BEGIN:VACL
ACLID:"No ACLs at all"
RIGHTS:CALUSER=ALL;REVOKE=ALL;OBJECT=RIGHTS,VACL,ACLID
END:VACL

5.  Access Rights Component Property

Property Name: RIGHTS

Purpose: This property specifies access rights for an authenticated
calendar user

Value Type: ACLRIGHTS

Property Parameters: Non-standard property parameters can be specified
on this property.

Conformance: This property can be specified in a "VACL" calendar com-
ponent.

Description: <to be supplied>

Format Definition: The property is defined by the following notation:

rights          = "RIGHTS" rightsparam ":" aclrights CRLF
rightparam      = *(";" xparam)

Dawson/Royer               Expires: June 1999           FORMFEED[Page 6]

Pre-Draft-Ideas              iCalendar ACL             December 13, 1998

Example: The following is an example of this property:

RIGHTS:CALUSER="guest";ACLID="VIEW FREE BUSY"

6.  VACL ID

Property Name: ACLID

Purpose: This property specifies the identifier for a "VACL" calendar
component.

Value Type: TEXT

Property Parameters: Non-standard property parameters can be specified
on this property.

Conformance: This property can be specified in "VACL" calendar com-
ponent.

Description: <to be supplied>

Format Definition: The property is defined by the following notation:

aclid           = "ACLID" textparam ":" text CRLF

Example: The following is an example of this property:

ACLID:"View Free Busy"

7.  Examples

7.1.  Allow read access to PUBLIC components.

Here all users are allowed to read all PUBLIC components:

BEGIN:VACL
ACLID:"VIEW ALL PUBLIC"
RIGHTS:CALUSER=ALL;GRANT=READ;OBJECT=CLASS;PUBLIC
END:VACL

Inside of a VEVENT the "VIEW ALL PUBLIC" ACLID is used:

BEGIN:VEVENT
RIGHTS:CALUSER="staff";ACLID="VIEW ALL PUBLIC"
 .
 .

Dawson/Royer               Expires: June 1999           FORMFEED[Page 7]

Pre-Draft-Ideas              iCalendar ACL             December 13, 1998

 .
END:VEVENT

7.2.  Examples of default ACLs.

The systems calendar administrator my wish the default for all calendars
in the store to allow read access to all PUBLIC components except VJOUR-
NAL.  So the following VACL might be stored at the calendar store level:

BEGIN:VACL
ACLID:"Default access for all calendars"
RIGHTS:CALUSER=ALL;GRANT=READ;OBJECT=CLASS;PUBLIC
RIGHTS:CALUSER=NONOWNER;REVOKE=READ;OBJECT=VJOURNAL
END:VACL

When a calendar is created, all owners would be given full access.

BEGIN:VACL
ACLID:"Default access for calendar named 'baseball'"
RIGHTS:CALUSER="user who owns baseball";GRANT=READ,MODIFY,CREATE,DELETE
 OBJECT=ALL
END:VACL

7.3.  Allow a designate to act on your behalf.

In this example the owner of the calendar has defined that his secretary
may only update PUBLIC and CONFIDENTIAL components.  The secretary will
not have access to PRIVATE entries.  This example might be stored at the
calendar level.

BEGIN:VACL
ACLID:"How I wish to designate"
RIGHTS:CALUSER="jane";GRANT=CREATE,READ,MODIFY,DELETE;OBJECT=ALL
RIGHTS:CALUSER="jane";REVOKE=CREATE,READ,MODIFY,DELETE;OBJECT=CLASS;PRIVATE
END:VACL

The implementation must adhere to and enforce the [ICAL] rules.  A newly
created VEVENT entered by a designate (jane) might look like this when
entered into the users (theBoss) calendar:

BEGIN:VEVENT
UID:123q23
DTSTART:19970903T163000Z
DTEND:19970903T190000Z
SUMMARY:Annual Employee Review

Dawson/Royer               Expires: June 1999           FORMFEED[Page 8]

Pre-Draft-Ideas              iCalendar ACL             December 13, 1998

CLASS:PUBLIC
CATEGORIES:BUSINESS,HUMAN RESOURCES
ATTENDEE;SENT-BY=MAILTO:[email-masked];MAILTO:[email-masked]
END:VEVENT

Dawson/Royer               Expires: June 1999           FORMFEED[Page 9]