Subject: Alternate to COALESCE

From: Doug Royer <[email-masked]>
Date: Wed, 06 Feb 2002 14:28:48 -0700

After seeing the latest VCAR proposal, it occurred to me that we
don't need COALESCE.

Instead of COALESCE, how about :

When you VQUERY where GRANT = SELF() and EXPAND:TRUE
you get single a logical VCAR reply where all of the VCARs
contents are merged for the current UPN.

If EXPAND is FALSE, your get multiple VCARS as stored.

An implementation MAY return EXPAND:TRUE results as if EXPAND:FALSE
was supplied. CS implementations may wish to restrict what
CUAs can see based on the authenticated UPN.

Example:

	BEGIN:VQUERY
	EXPAND:TRUE
	QUERY:SELECT * FROM VCAR WHERE GRANT = SELF()
	END:VQUERY

You don't need DENY = SELF(), because that is the default for
what you don't have access to anyway.

And when not selected by CARID:

	BEGIN:VQUERY
	EXPAND:FALSE
	QUERY:SELECT * FROM VCAR WHERE GRANT = SELF()
	END:VQUERY

The CS MAY return only the any existing VCARs that
apply to SELF() for which SELF() has GRANT access, and
READ access to the VCAR, but restricted to only what applies
to the UPN.

The difference between these two is the the first produces
one VCAR. The second returns multiple VCARs, where each one
is tagged with CARID and may or might not be the original
VCAR - but is guaranteed to apply to SELF().

---

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 07 Feb 2002 15:40:15 -0500

I agree that there must be a way to specify that we
only want the VCARs that pertain to the authenticated
user to be returned.

But I don't see why you think it will be easier to the
CUA to handle the following coalesced VCAR: 

     BEGIN:VCAR
     BEGIN:VRIGHT
     GRANT:[email-masked]
     PERMISSION:READ
     SCOPE:SELECT DTSTART,DTEND FROM VEVENT
     END:VRIGHT
     BEGIN:VRIGHT
     GRANT:[email-masked]
     PERMISSION:READ
     PERMISSION:MODIFY
     SCOPE:SELECT * FROM VEVENT WHERE CLASS = 'PUBLIC'
     END:VRIGHT
     END:VCAR

than these two separate VCARs?

     BEGIN:VCAR
     CARID:abcd12345-1
     BEGIN:VRIGHT
     GRANT:[email-masked]
     PERMISSION:READ
     SCOPE:SELECT DTSTART,DTEND FROM VEVENT
     END:VRIGHT
     END:VCAR

     BEGIN:VCAR
     CARID:abcd12345
     BEGIN:VRIGHT
     GRANT:[email-masked]
     PERMISSION:READ
     PERMISSION:MODIFY
     SCOPE:SELECT * FROM VEVENT WHERE CLASS = 'PUBLIC'
     END:VRIGHT
     END:VCAR

I'll reply to your message once I understand this.

Regards,
Bernard
-- 
Bernard Desruisseaux                    mailto:[email-masked]
Research & Development                  Tel.  : +1 514 733-8500 x4213
Steltor                                 Fax   : +1 514 733-8878

---

From: Doug Royer <[email-masked]>
Date: Thu, 07 Feb 2002 15:53:58 -0700

Bernard Desruisseaux wrote:
> ...

Fist I like the VRIGHTs vs the old VCAR model. It looks
much more clean.

My reply:

As the order of VCARs is unspecified and the order they
have been deposited into the CS in interminable:

(1) Because for the predefined VCARs in a CAR-MIN CS, the second
    is not be defined in CAR-MIN, so the CUA would have NO way to ask
    for the second one so it MUST HAVE been specified in at least
    one of the predefined VCARS. Therefore a CUA must be able to
    query for this and it would have to come back in combined format
    in at the very least the predefined VCAR it came from.

(2) Given these two VCARs that effect [email-masked]'

	BEGIN:VCAR
	CARID:XX
        BEGIN:VRIGHT
        GRANT:*
        PERMISSION:READ

	BEGIN:VCAR
	CARID:YY
	BEGIN:VRIGHT
	DENY:[email-masked]
	PERMISSION:READ
	SCOPE:SELECT * FROM VEVENT WHERE UID = 'three'
	END:VRIGHT

     Now if you add multiple exceptions like (2) above,
     it seem to me that you are going to enter a undefinable
     race condition between which VCAR overrides which VCAR.
     But if they are in the same VCAR, then the entire set
     of GRANT/DENY is one block that is computed together.

     If you apply CARID:XX first, then apply CARID:YY
     then [email-masked]' does not have access to UID = 'three'.

     But if you were to apply UID:YY first then UID:XX,
     then [email-masked]' would have access to UID = 'three'.

I don't see any option except to combine them so that one
VCAR set is 'the access'.

So, I don't think we can mandate they come back separately because
for complex exceptions, the order of VCARs is specified in CAP
to be insignificant (and it needs to be or we have another
huge problem to solve). 

For this one example, a smart CS could return:

	BEGIN:VCAR
	CARID:XX
        BEGIN:VRIGHT
        GRANT:[email-masked]
        PERMISSION:READ
        SCOPE:SELECT DTSTART,DTEND FROM VEVENT WHERE UID != 'three'
	END:VRIGHT
	END:VCAR

But that would require us to mandate that all CSs have
what I will call "VCAR optimizers" - and I do not think
that is going to happen.

I thought of suggesting adding LAST-MODIFIED to VCARs and apply
the VCARs in that order, but that will not allow a CUA to
override decreed VCARs that would be part of the query result set.
Resulting in the same problem, you have to be able to specify
multiple VRIGHTS in the same VCAR so you do not have to guess
out the correct order to apply VCARs that are by definition
unordered.

The CS only has to remember the VARs sent to it and be able
to return them (non-COALESCED). However it has to apply them
all at once (COALESCED) inside the CS.

---

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 07 Feb 2002 22:04:41 -0500

> Fist I like the VRIGHTs vs the old VCAR model. It looks

:-)

>     in at the very least the predefined VCAR it came from.

Sorry.  I've read this paragraph multiple times and
I still can't make sense out of it.  Perhaps you can
reformulate it.  :-(

> VCAR set is 'the access'.

There is no ambiguity here.  CAP is clear:

   The access for a particular UPN is the union of all grants
   for that UPN minus the union of its denies.

So you compute the union of all the GRANTs of all the
VCARs and then subtract the union of all the DENYs of
all the VCARs.

Precedence is most certainly NOT a reason to group
multiple VRIGHT in a single VCAR. The VRIGHT component
was introduced to allow multiple rights (VRIGHT) to
share the same CARID.

> what I will call "VCAR optimizers" - and I do not think

Yep! It's not gonna happen! :-)

Now that you know that we don't have problems with
precedence.  Do you still think we need a way to
return ALL VRIGHTs in a single VCAR?

I still can't see why we would need it.

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Fri, 08 Feb 2002 11:45:02 -0700

> I still can't make sense out of it.  Perhaps you can

Given one predefined VCAR that has several VRIGHT components.
The CS is going to return that single complex VCAR when asked.
So any CUA that ever asks for any VCAR is going to have to
be able to parse complex VCARs. So why split out the VRIGHTs
components into separate VCAR - that only increases the byte
overhead and gains nothing.

I am not saying that they can not be split. I am saying that
there is no point in splitting them when they are already
defined together. So a CUA MUST be able to deal with them
combined - and separate.

>    for that UPN minus the union of its denies.

Yes - duh - I even think I wrote that sentence :-)
I must be getting old.

> VCARs and then subtract the union of all the DENYs of

After thinking about it, maybe it should be re-worded
the way you have stated (DENYs in the VCARs) which reflects
the way it is. Otherwise, as the default is deny, everything
gets subtracted.

> I still can't see why we would need it.

Not mandated, but there is no reason for a CS to split
an already  defined VCAR into multiple parts. So both
must be allowed.

---

From: Bernard Desruisseaux <[email-masked]>
Date: Fri, 08 Feb 2002 16:10:09 -0500

> defined together. So a CUA MUST be able to deal with them

I agree.  The CS MUST NOT split out the VRIGHT contained
in a single VCAR into separate VCARs.

What I'm questionning is why should the CS have the ability
to merge VRIGHT components contained in separate VCARs in a
single VCAR (a.k.a. the coalescence of VCARs).

> the way it is. Otherwise, as the default is deny, everything

The precedence rule could also be written as follow:

  If two rights exist and are in conflict,
  the right that denies access always takes
  precedence over the right that grant access.

> an already  defined VCAR into multiple parts. So both

I agree that both MUST be allowed.

The only transformation the CS should apply to the
VCARs before returning them is modifying the GRANT
and DENY properties for security reasons.  As was
dicussed and agreed several times.

So far we don't seem to need coalescence of VCAR.
We just need the ability to have multiple VRIGHT
in a single VCAR.

Agree?

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Fri, 08 Feb 2002 15:23:13 -0700

>  precedence over the right that grant access.

And add 'in VCARs' (as the denies are implied if they
do not exist and those are not to be considered in conflict)?

> We just need the ability to have multiple VRIGHT

What is the difference? If I make up VCARs that do not
really exist so that SELF() can only see a VCAR that
only effects SELF() for security reasons - that is a
coalesced VCAR. Correct?

---

From: Bernard Desruisseaux <[email-masked]>
Date: Mon, 11 Feb 2002 11:44:29 -0500

> do not exist and those are not to be considered in conflict)?

"If two rights specified in VCAR components are in conflict,
 the right that denies access always takes precedence over
 the right that grant access."

Correct?

> only effects SELF() for security reasons - that is a

We need to stop talking about coalescence of VCARs since
there is no coalescence per say.  Returned VCARs will
never contain more VRIGHT components than their stored
version.

We only need the ability to return VCARs with the GRANT
and DENY properties "instantiated" to SELF().

Could we simply specify that:

"When EXPAND is TRUE, only VCARs that pertain to the
 authenticated user MUST be returned, and the GRANT
 and DENY properties of the returned VCARs MUST only
 specify the UPN of the authenticated users."

Agree?

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Mon, 11 Feb 2002 13:39:18 -0700

>  the right that grant access."

Yes.

>  specify the UPN of the authenticated users."

No did not agree to drooping COALESCE. :-)

So how about adding this:

  "A CS MAY return a dynamically generated VCAR in response to
   a query that is generated by the CS at the time of the query.
   This generated VCAR will have the DECREED property set to true.
   This will allow an implementations to limit the contents to
   the currently authenticated UPNs access when security does
   not permit non-owner UPNs to see the access rights that may
   effect other UPNs. The CARID of this dynamically generated
   VCAR MUST BE 'DYNAMIC'.

Okay?

---

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 12 Feb 2002 10:05:09 -0500

>    effect other UPNs. The CARID of this dynamically generated

1- I don't see the shadow of a hint of a suggestion of
   the concept of "COALESCE" in this proposal.  Coalesce
   means "unite into one".  We don't need to unite multiple
   VCAR components into one to limit their contents to the
   access rights that pertain to the currently authenticated
   user.  Under no circumstances will the CS need to return
   VCAR components with more VRIGHT components than their
   stored version.  On the contrary, the CS MAY return VCAR
   components with less VRIGHT components than their stored
   version.

2- By definition DECREED VCARs are persistent and immutable.
   A DECREED VCAR with CARID:DYNAMIC is simply nonsensical.

CAP just need to specify the following:

When EXPAND is TRUE, the CS MUST only specify the UPN of the
currently authenticated user in the GRANT or DENY property of
the VRIGHT components of the returned VCAR components. VRIGHT
components that don't pertain to the currently authenticated
user MUST be left out of the returned VCAR components.

The CS MAY only specify the UPN of the currently authenticated
user in the GRANT or DENY property of the VRIGHT components
of the returned VCAR components not owned by the currently
authenticated user for security reasons.  VRIGHT components
that don't pertain to the currently authenticated user MAY be
left out of the returned VCAR not owned by the currently
authenticated user for security reasons.

Agree?

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Tue, 12 Feb 2002 09:09:55 -0700

Bernard Desruisseaux wrote:

>    user. 

I am certain you don't. Your implementation is free to
return everything to everyone.

I am certain I do need the filtering described in CAP.
I need them so that I can limit what access a authenticated
UPN can see. And that limit must include the ability to NOT
show the currently authenticated UPN what access right other
users have as this is for security reasons. If I see VCAR CARID:foo
and CARID:foo has:

	PERMISION:another-upn ...

Then I have given out security information that the current
user does not need to have permission to see. 

This still exists in CAP and it needs to stay:

   The return values are subject to VCAR filtering.  That is, if the
   request contains properties to which the UPN does not have access,
   those properties will not appear in the return values.  If the UPN
   has access to at least one property of events, but has been denied
   access to all properties called out in the request, the response will
   contain a single REQUEST-STATUS property indicating the error. ...

This applies to all components - including VCARs. Which
means that what you get MAY not include all of any component
contents when you don't have access. I do not see a valid reason to
limit this only non-VCARs.

---

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 12 Feb 2002 12:03:54 -0500

>         PERMISION:another-upn ...

PERMISSION does not specify UPN.  GRANT and DENY do.

> limit this only non-VCARs.

Douglas, you digress again.

How did you come up with the idea that my proposal was
meant to replace the text you quoted?

My proposal --- have you simply read it? --- provides
text for what YOU proposed back in December and which
was agreed on the list.

http://www.imc.org/ietf-calendar/mail-archive/msg02372.html
http://www.imc.org/ietf-calendar/mail-archive/msg02535.html
http://www.imc.org/ietf-calendar/mail-archive/msg02376.html

So again, I propose to add the following text to CAP:

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Tue, 12 Feb 2002 11:05:27 -0700

> meant to replace the text you quoted?

When you said in the email that I replied to:

    "...We don't need to unite multiple
    VCAR components into one to limit their contents to the
    access rights that pertain to the currently authenticated
    user. ..."

> user MUST be left out of the returned VCAR components.

And add:

  And their contents MAY BE filtered or modified to eliminate
  from the reply set any information that does not directly effect
  the currently authenticated UPN.

And for the purpose of this UPN at the time they ask, the
result is in effect decreed to them, add:

  And when an existing VCAR reply is modified, it MUST BE
  tagged with the property DECREED set to TRUE as this filtered
  VCAR can not be modified by its CARID by the currently
  authenticated UPN or any UPN.

OR add:

  The CS MUST include as part of that filtered VCAR, a
  VRIGHTS component that prohibits the currently authenticated
  UPN from modifying or deleting this virtual VCAR.

And these filtered or modified VCAR replies need to be tagged
so the UPN does not think that they are 'the' VCAR with CARID.
So I think we need to add something like:

  And the name of any filtered VCAR that is a subset of
  existing VCARs needs to have a CARID that does not conflict
  with existing CARID. 

So I propose we call those filtered virtually decreed VCARS
'DYNAMIC'.
  
> authenticated user for security reasons.

Add:
  Or modified so that only the currently authenticated UPN
  is in the result set. Example:

	GRANT:joe,sam,tom

  May be returned as:

	GRANT:joe

So that JOE can't tell that sam and tom even exist as valid UPNs.

---

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 12 Feb 2002 14:18:26 -0500

>   the currently authenticated UPN.

But I don't understand, that's already covered in the text
I proposed.

The VRIGHT component that pertains to you will only
specify your UPN in the GRANT or DENY property:

"... the CS MUST only specify the UPN of the
 currently authenticated user in the GRANT or DENY property of
 the VRIGHT components of the returned VCAR components."

and the VRIGHT component that don't pertain to you
will not be returned to you:

"VRIGHT components that don't pertain to the currently
 authenticated user MUST be left out of the returned VCAR
 components."

what information is left to be "filtered" or "modified" ?

>   authenticated UPN or any UPN.

This is not needed.  And again, DECREED:TRUE means that
the VCAR is PERSISTENT and IMMUTABLE, that is, a decreed
VCAR is guaranteed to EXISTS FOREVER and to NEVER CHANGE.

>   UPN from modifying or deleting this virtual VCAR.

That doesn't make sense.  That VCAR would not exist on the
CS, so the CU could still modify the VCAR anyway, that is,
if he is granted the right to do so.

On the other hand, I should probably change the second
paragraph of my proposal to apply to the "VCAR components
for which the currently authenticated user doesn't have the
MODIFY permission granted" instead of the "VCAR components
not owned by the currently authenticated user".

> So I propose we call those filtered virtually decreed VCARS

I disagree.  If I query the VCAR with CARID:REQUESTONLY in
your VAGENDA it must be returned with CARID:REQUESTONLY,
even if all the GRANT and DENY that does not pertain to you
have been removed.  Otherwise the CUA would be totally
confused when performing the following search:

  BEGIN:VQUERY
  QUERY:SELECT * FROM VCAR
   WHERE CARID = 'REQUESTONLY' OR
   CARID = 'READBUSYTIMEINFO'
  END:VQUERY

How would the CUA be able to distinguish which of the 2
returned VCAR components is which?

> So that JOE can't tell that sam and tom even exist as valid UPNs.

Again, that's already covered in the text I proposed.

"The CS MAY only specify the UPN of the currently authenticated
 user in the GRANT or DENY property of the VRIGHT components
 of the returned VCAR components ... "

Proposal (#2) :

For security reasons, the CS MAY specify only the UPN of the
currently authenticated user in the GRANT or DENY property of the
VRIGHT components of the returned VCAR components for which the
currently authenticated user doesn't have the MODIFY permission
granted.  Furthermore, VRIGHT components that don't pertain to
the currently authenticated user MAY be left out of the returned
VCAR for which the currently authenticated user doesn't have the
MODIFY permission granted.

Okay?

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Tue, 12 Feb 2002 13:41:23 -0700

I think we may be agreeing, it may be a wording issue.

> VCAR is guaranteed to EXISTS FOREVER and to NEVER CHANGE.

No - it means the CUA can not change it. The CS administrator
may change it over time. To the CUA for any given session,
they do not change.

> user MUST be left out of the returned VCAR components.

(supply? not specify?)
When EXPAND is TRUE, the CS MUST only supply the UPN of the ...
                                      ^^^^^^

> Okay?

Yes. Now a question.

Will the CUA EVER be able to modify the results of the
EXPAND:TRUE generated VCAR that the CS sent back to the CUA
as the result of a query? I would think 'no' because this
made up VCAR does not really exist as sent back.

If no - then it needs to be marked DECREED? Because for
the life of the CAP session - it is not changing.

If not marked DECREED, then there MUST be a made up
VRIGHT in the returned set that tells the CUA it can not
modify the returned VCAR by using the returned CARID?
Otherwise it may apply another VCAR results from another
EXPAND:FALSE query and assume that the EXPAND:TRUE VCAR
results are modifiable. But this seem like too much
data - so just mark it DECREED?

OR - The result set coming back from the CS as the result
of a query from EXPAND:TRUE must NEVER use a CARID that already
exists - otherwise, it will be impossible to tell what the
VCAR with CARID really is. Or if the VRIGHTS of the EXPAND:FALSE
CARID apply to the EXPAND:TRUE CARID VCARs. So I proposed
that these generated VCARs always have a CARID of DYNAMIC.
And we define that any contents of a CARID:DYNAMIC VCAR
are read-only, and only valid for the current session for
the curren UPN.

Then ONE VCAR can be used that only gives them READ access
and denies WRITE, MODIFY, and DELETE access to any generated
(dynamic) VCAR. Otherwise there has to be one more VRIGHT
for each made up on the fly results.

Agree?

---

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 12 Feb 2002 16:26:31 -0500

> When EXPAND is TRUE, the CS MUST only supply the UPN of the ...

Agreed with "supply".

> as the result of a query?

1- The CUA doesn't "modify results", it modifies components
   stored in the CS.

2- The means used by the CUA to come up with a replacement
   value for a stored component is beyond our control.

3- When managing VCAR components it is expected that CUA
   will NOT specify EXPAND:TRUE.  But again, there is
   nothing we can do to prevent CUA to do stupid things!

4- CUA MAY specify EXPAND:TRUE when they are querying
   VCAR components for evaluation purposes.

I hope that answer your question.

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Tue, 12 Feb 2002 15:57:29 -0700

> 1- The CUA doesn't "modify results", it modifies components

The 'results' are a valid VCAR with a BOGUS CARID.
Because the CARID is not 'the' CARID.

>    value for a stored component is beyond our control.

No, if the CS restores a filtered VCAR with a valid CARID,
then how would the CUA know that it is filtered? So it
would not know that it can't try.

>    nothing we can do to prevent CUA to do stupid things!

The CUA will specify EXPAND:TRUE in the query. That is
the proposal that I sent out as "Alternate to COALESCE"
that we are not debating.

>    VCAR components for evaluation purposes.

Then why in (3) above do you call it 'stupid' ?

> I hope that answer your question.

You have answered none of my questions, you edited them out
of your reply and ignored them completely. Here they are again:

Yes. Now a question.

the current UPN.

Agree?

---

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 12 Feb 2002 19:39:50 -0500

> Because the CARID is not 'the' CARID.

It's not because you don't get the full content of
the VCAR that its CARID is BOGUS.

What next?  You are going to tell me that the UID of
a VEVENT for which I'm not granted the RIGHT to READ
the LOCATION property should be returned to me with a
different UID?  Think about it.  Come on.

> would not know that it can't try.

Read the proposal.  The CUA will only get partial VCAR
components if (1) he explicitly requests the CS by specifying
EXPAND:TRUE in the VQUERY (in which case it knows that the
VCAR may not be complete) or if (2) he is not granted the
right to modify the VCAR (in which case there is no issue).

> that we are not debating.

The CUA should only specify EXPAND:TRUE if it wants to
figure out the access right of the currently authenticated
user NOT when it wants to administer them.  That's the
whole point!

> Then why in (3) above do you call it 'stupid' ?

If the CUA's intent is to administer VCAR, that is,
get them from the CS to modify their content later
on, well yes, it would have to be very stupid.

If the CUA's intent is to figure out rights that are
granted and denied to the currently authenticated user,
then it may specify EXPAND:TRUE to only get the useful
information.

> of your reply and ignored them completely. Here they are again:

Well, I've had entire proposals edited out and ignored
completely in replies.  Very annoying isn't it?

> made up VCAR does not really exist as sent back.

That's irrelevant.  See above.

> the life of the CAP session - it is not changing.

That's not true.  You read a VCAR stored in my VAGENDA in
which you are granted some rights.  2 seconds later I deny
you those rights.  The VCAR changed.  QED.

> data - so just mark it DECREED?

That doesn't make sense.  What if the CUA simply wants to
know if it can modify a given VCAR in his VAGENDA?
Querying with EXPAND:TRUE would always have him believe
that he is denied the right?   That's ridiculous.

> for each made up on the fly results.

Very clever!  I would then receive all the VCAR components
with predefined CARID with CARID:DYNAMIC.  Do you really
want to make VCAR with predefined CARIDs unusable?

Are we done yet?

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Tue, 12 Feb 2002 19:02:20 -0700

> different UID?  Think about it.  Come on.

The difference is that the OWNER will generally have
full access to the owners VEVENTS. But may not have
full access to some of the VCARs that effect the owner.
How will OWNER know that the results of the VQUERY are
trimmed? For that I am going to send DECREED so that
the OWNER does not attempt to change them, even
when another UPN may not get DECREED for the exact
same query.

My only other choice is to generate N number of VRIGHTs,
one for each UPN times the number of VCARs they might see
just so they can be returned when EXPAND:FALSE. I elect to
use DECREED and dynamically return them when the UPN does
not have MODIFY rights (and maybe DELETE rights - I am still
think about that).
 
> right to modify the VCAR (in which case there is no issue).

I for one am going to dynamically add DECREED when the
UPN does not have MODIFY rights. The effect is the same
and requires less VRIGHTS with complex VCARs. And I am
going to return dynamically created CARIDs so that they
do not have to exist in your next session.

I am also going to dynamically return results. I think that
you are missing a big security issue here that may be
solved by using DECREED and trimming the results.

> user NOT when it wants to administer them.  That's the

No. I am not going to let you see all of some CALSTORE
VCARs that were copied to your calendar when it was created.
If you don't need to administer them - that is my
point. If you ask for REQUESTONLY and EXPAND:FALSE, I am
going to trim out what you don't need to see so that a
hacker-CUA can not find out what to try next. So that
you can't see that user 'JOE' is explicitly restricted
from the CS - which includes your calendar.

The same will be true for ANY VCAR where UPN does not
have MODIFY rights.

> on, well yes, it would have to be very stupid.

Yes, but for the CUA that is not administering VCARS,
they don't need to see everything that does not effect them.
No matter what the value of EXPAND - for security reasons.

I am just making sure that when I mark them as DECREED
and trim them down, that we still have interoperability.
I think we do.

> then it may specify EXPAND:TRUE to only get the useful

Unless they are malicious - and that is why they will be trimmed
down anyway and marked as DECREED for any UPN that does not
have MODIFY permission.

> you those rights.  The VCAR changed.  QED.

Good, then we agree that your statement was a typo
when you said:

	"This is not needed.  And again, DECREED:TRUE means that
	the VCAR is PERSISTENT and IMMUTABLE, that is, a decreed
	VCAR is guaranteed to EXISTS FOREVER and to NEVER CHANGE."

> want to make VCAR with predefined CARIDs unusable?

Only the ones where you do not have MODIFY permission
and did not explicitly ask for them. Because any random CUA does not
need to know them. Any random CUA only needs to know what it
has access to in the CS. It does not need to know why or the
name of the CARID if it can't do anything with it and it does
not matter the value of EXPAND in that case.

And it does not stop the CUA from asking for CARID's by
name (predefined or not). It means that if you do EXPAND:TRUE,
your MAY see one VCAR and its name is DYNAMIC.

If you have EXPAND:FALSE, your are going to see a lot
of VCARs:
	
 Some of them with predefined CARIDs which MAY be marked DECREED.

 Some with CARID's when you have MODIFY access.

 And the rest will be bunched into a factious CARID of DYNAMIC
 and it will be marked DECREED.

---

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 12 Feb 2002 22:30:27 -0500

Doug Royer wrote:
> trimmed?

If the owner specified EXPAND:TRUE he knows.  If the owner
doesn't have the right to modify the components he doesn't
need to know.  That's not rocket science...

> For that I am going to send DECREED so that

Why do you insist on giving out security information that
the current user does not need to know?  The thruth of the
matter, is that the user should not know that he is given
a trimmed version (unless he's granted the right to modify
the component and did not specified EXPAND:TRUE).

> do not have to exist in your next session.

Well I wish you the best of luck with the VCAR with
predefined CARID!

> solved by using DECREED and trimming the results.

I don't think so.  In fact, you will be the one leaking
security information. "Attention hacker attention, the
returned VCAR is trimmed. I repeat: The returned VCAR is
trimmed."

> The same will be true for ANY VCAR where UPN does not

What is the problem?  If I don't have the right to
modify them, then I'll be given a trimmed version.
That's all.

> No matter what the value of EXPAND - for security reasons.

If the CUA doesn't provide the ability to administer VCAR
components then it should specify EXPAND:TRUE. If it does
not. Too bad. It will receive the full content of the VCAR
components for which it is granted the right to modify.
No problem here.

> and trim them down, that we still have interoperability.

Marking VCAR on the fly as DECREED:TRUE is a sure way to
break interoperability.  Some CUA could assume that the
VCAR will not change while it might (since the stored
version is not DECREED).

> down anyway and marked as DECREED for any UPN that does not

If the UPN doesn't have the right to modify the VCAR,
sure, trimmed it down.  There is not need to mark
the VCAR has DECREED though.  If the user can't
modify the VCAR, that's none of his business that
he was given a trimmed down version of the VCAR.
In fact, you really don't want him to know that!

>         VCAR is guaranteed to EXISTS FOREVER and to NEVER CHANGE."

No.  We are in total disagreement.  VCAR components with
DECREED:TRUE in the calendar store are persistent and
immutable.  What you are proposing is to add DECREED:TRUE
on the fly to trimmed VCAR components.  Since the VCAR stored
in the CS may not have DECREED:TRUE, yes, I could changed it.
Adding DECREED:TRUE on the fly to VCAR is evil.

> and did not explicitly ask for them. 

Why are you wasting your time trying to come up with
odd exception to something we don't need in the first
place?

> Because any random CUA does not

So what you are saying is that VCAR with predefined
CARID must retain their orignal CARID, and for the
other VCAR, well the CUA doesn't care.  So why bother
changing the CARID to DYNAMIC then?

>  and it will be marked DECREED.

Marking VCAR as DECREED:TRUE on the fly:

1- Is not needed;
2- Leaks security information;
3- Breaks interoperability.

Changing the CARID of VCAR on the fly:

1- Is not needed;
2- Makes using predefined CARID a pain.

Regards,
Bernard