[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: VCAR: RIGHTS Value Type Ambiguous
Doug Royer wrote:
>
> Bernard Desruisseaux wrote:
> >
> > Doug Royer wrote:
> > >
> > > Bernard Desruisseaux wrote:
> > > >
> > > > The semantic of OBJECT and VALUE rule parts is ambiguous.
> > > >
> > > > To illustrate this fact, here's possible interpretations
> > > > of two very simple VCARs.
> > > >
> > > > Example 1:
> > > >
> > > > BEGIN:VCAR
> > > > CARID:UPDATEPARTSTATUS
> > > > GRANT:UPN=*;ACTION=MODIFY
> > > > ;OBJECT=PARTSTAT:VALUE=*
> > > > ;OBJECT=ATTENDEE;VALUE=SELF
> > > > END:VCAR
Unless I'm missing something, your first interpretation of
this VCAR:
> > > For example (1) this GRANT would apply to you if:
> > >
> > > you wanted to MODIFY
> > > And the PARTSTAT object had any valule.
> > > and ATTENDEE is <self>.
is different from your original intent:
> I am the author of VCAR - and my intent was to show that
> you can restrict them to only be able to modify the PARTSTAT.
Your first interpretation was basically saying that
OBJECT=PARTSTAT:VALUE=*
meant that we don't care what the value of PARTSTAT is,
but your intent was to say that the user is only allowed
to modify the PARTSTAT. What would be the VCAR that would
translate your intent clearly?
>
> > As I mentionned in my previous post, the OBJECT and VALUE rule
> > parts are trying to specify too many things at once. For instance,
> > this VCAR is trying to restrict the stored objects you are allowed
> > to MODIFY (ATTENDEE set to <self> in our case), and to specify
> > restriction on the submitted object (the submitted object can
> > only change the value of PARTSTAT in our case). Trying to specify
> > both together with OBJECT and VALUE rule parts causes confusion.
>
> Why? Your previous post did not seem make that point.
> It only shows me that there needs to be more text and examples.
>
> > >
> > > So for a VEVENT with with UPN 'x':
> > >
> > > BEGIN:VEVENT
> > > ...
> > > ATTENDEE;PARTSTAT=NEEDS-ACTION:Z
> > > ATTENDEE;PARTSTAT=NEEdS-ACTION:x
> > > ...
> > > END:VEVENT
> > >
> > > The VCAR allows you to modify ONLY the one that matches.
> > > BEFORE AND AFTER.
> >
> > BEFORE AND AFTER? Where is that specified?
>
> It applies to the ACTION, where does it say that it only
> applies to half of an ACTION?
>
> Remember - ACTION means command, so in that context, why
> would you think that it would not apply to all of the command?
BTW, the mapping between ACTION and command is NOT 1:1.
See my post on why we can't have a MOVE ACTION:
http://www.imc.org/ietf-calendar/mail-archive/msg03230.html
>
> > How would I be able to say that you are only allowed to
> > modify PARTSTAT from NEEDS-ACTION to ACCEPTED?
>
> No such requirement exists. It does not seem to be a reasonable
> need. An ATTENDEE can not chagne from ACCPTED to DECLINED?
> Plus they still have to follow the rules of iTIP.
That's beside the point. More generally:
How would I be able to say that you are only allowed to
modify property P from value V1 to value V2?
In the case of the create command we can easily set
restrictions on the new values, but it doesn't seem
to be the case with the modify command. That doesn't
make sense.
> > You could propably argue that it's not a requirement, but
> > then Access Rights as a whole is marked as "deferred" in
> > the CAP requirements document.
>
> And it was later un-deferred by this WG. Do you want
> NO access control in CAP? Or are you proposing that
> it needs to be added as a requirement?
>
> > >
> > > > (a) Anybody is granted the right to modify, to any value, the
> > > > PARTSTAT parameter of ATTENDEE properties set to himself;
> > > >
> > > > (b) Anybody is granted the right to modify, to any value, the
> > > > PARTSTAT parameter of any ATTENDEE properties, as long as
> > > > there is one ATTENDEE property set to himself in the
> > > > component;
> > >
> > > NOT true as only ONE of them match, if <self>
> > > is not 'Z' it does not match the first one.
> > >
> > > > (c) Anybody is granted the right to modify, to any value, the
> > > > PARTSTAT parameter, as long as he modifies the ATTENDEE
> > > > property to himself as well;
> > >
> > > NOT true as it is only true IF he is the ATTENDEE,
> > > else he can not modify it. And yep - your VCAR allows them to
> > > modify the value of the ATTENDEE, as long as it is already
> > > set to 'x'. And you could modify the value, as long as the
> > > rule still was valid - so the only thing you could modify
> > > it to is 'x'
> > >
> > > > (d) Anybody is granted the right to modify the value of any
> > > > ATTENDEE property to himself, regardless of the stored
> > > > value of the parameter PARTSTAT.
> > >
> > > They could modify all ATTENDEEs from UPN 'x' to UPN 'x'.
> > > All other ATTENDEE values don't match.
> >
> > If you think OBJECT and VALUE rule parts are not ambiguous,
> > can you propose a different VCAR for each of the four
> > interpretations that I wrote?
>
> I don't think I understand your question.
>
> (b) Not reasonable, why would you want anyone that is also
> an ATTENDEE to be able to modify anyones elses PARTSTAT?
>
> (c) Not reasonable, why would you want anyone to modify the
> value another ATTENDEE to themselves?
>
> (d) Same as (c).
That's beside the point. We are not here to judge whether
specific VCARs are reasonable or not. We simply have to make
sure that VCARs are flexible enough to allow users to specify
their access rights the way they want regardless if it seems
reasonable to you or not.
I still don't see how I could write a VCAR for the following
statement:
Anybody is granted the right to read all the ATTENDEE
properties of VEVENT components for which he is the
ORGANIZER.
(1) The set of stored objects on which the specified
ACTION is granted or denied:
VEVENT components that have the ORGANIZER
property set to SELF.
(2) The part of the selected objects on which the
specified ACTION is granted or denied.
All ATTENDEE properties only (i.e., we
are not granting the right to read the
ORGANIZER property).
>
> > >
> > > > Example 2:
> > > >
> > > > BEGIN:VCAR
> > > > GRANT:UPN=*;ACTION=READ;OBJECT=*;
> > > > ;OBJECT=ORGANIZER;VALUE=SELF
> > > > END:VCAR
> > > >
> > > > (a) Anybody is granted the right to read everything in
> > > > components for which he is the ORGANIZER;
> > > >
> > > > (b) Anybody is granted the right to read the ORGANIZER
> > > > property of components for which he is the ORGANIZER.
> > >
> > > 'property of components' ?
> > >
> > > I read (a) and (b) as the same. If the VALUE of ORGANIZER
> > > is 'x', you can read it.
> > >
> > > I don't see your points.
> >
> > How would I write a VCAR to grant you the right to read
> > everything, that is, not only the ORGANIZER property, in
> > components that have the ORGANIZER property set to yourself?
>
> If you mean you want to be able to read anything?
>
> GRANT:UPN=*;ACTION=READ;OBJECT=*
>
> Or you want to be able to ONLY read components that have
> yourself as organizer?
>
> GRANT:UPN=*;ACTION=READ;OBJECT=VEVENT,VTODO
> ;OBJECT=ORGANIZER;VALUE=self
Now, how would I write a VCAR that only grants me the
right to read the ORGANIZER property of VEVENT only,
but only when ORGANIZER is set to myself?
> > After all the energy that was spent in this WG to define
> > CAP-QL, I think it would be a big mistake to use a different
> > selection mechanism in VCARs. Do you really want to go over
> > all the same issues again?
>
> They are different issues, there is NO ACL of any kind in CAP-QL.
Of course there is no ACL in CAP-QL. It's a query language.
All I'm saying is that we should be using the same query
language to specify the object to which a given access right
applies.
> Using CAP-QL won't work, You would have to define a way
> to have
>
> component.property.paramater
> component.property.paramater.value
> component.component.property.paramater
> component.component.property.paramater.value
Sorry, I don't understand what you are saying.
CAP-QL shouldn't have any problem defining "the set of stored
objects on which the specified ACTION is granted or denied".
Otherwise, we need to fix it.
>
> It's not the same model because querying for something is not
> the same problem as listing what they have access to.
I agree it's not the same problem. But why are VCARs trying
to solve different problems all at once?
Regards,
Bernard
--
Bernard Desruisseaux mailto:bernard@xxxxxxxxxxx
Research & Development Tel. : +1 514 733-8500 x4213
Steltor Fax : +1 514 733-8878