[Ietf-calsify] Event class
bernard.desruisseaux at oracle.com
Thu Aug 26 11:18:01 PDT 2004
Harrie Hazewinkel wrote:
> Bernard Desruisseaux wrote:
>> Remember that iCalendar doesn't define an _access control_ model.
> True, but it has the CLASS-property. So the statement of
> "doesn't" is not completely right. It depends on how you define it.
> Only CLASS is a very rough ACM.
iCalendar specifies a data representation. It doesn't say anything
about "accessing" data, let alone about "controlling" its access.
An access control model should allow you to specify "who" is
granted or denied which "privilege" on "what". CLASS is only
useful for the "what".
> We (here at I.Net) have implemented a CAP server with ACL for
> as well inidvidual users as with groups.
> Your example speaks only of 'viewing' data, but how about modifying
> and/or replying(accepting) an invitation. The client needs to know some
> information about that. Of course, you may say that is a CAP only issue,
> but then again the information must be conveyed in combination with
> the VEVENT.
Here's an example for modify:
- User B (my assistant) is allowed to modify my PUBLIC and CONFIDENTIAL
- User B (my assistant) is not allowed to modify my PRIVATE calendar
I think you should always have the right to reply to an invitation! :-)
Whether somebody else is granted the right to reply to an invitation on
your behalf is indeed more tricky. Would you base the ACE that grant or
deny the right to reply to invitation on the value of the CLASS property
set by the originator (i.e., organizer)? Hummm... It would probably be
safer to discard the received CLASS and to specify an ACE for
unspecified CLASS (e.g., deny when in doubt).
> In the end we have custom properties for this, since we are also in the
> luck we have the client side. On top of that our CAP server makes sure
> that every user receiving a VEVENT gets only those properties he/she may
> view. For instance, if a user may only see DTSTART/DTEND it only sends
> those properties (you should not trust the final client to filter them).
Would you mind sharing your custom properties?
> The class property is only a mean to provide a 'rough' access control by
> the originator.
Sorry to insist but CLASS specifies classification not control.
More information about the Ietf-calsify