Re: Alternate to COALESCE

[Doug Royer <Doug@xxxxxxxxx>]

Bernard Desruisseaux wrote:
> 
> Doug Royer wrote:
> >
> > Bernard Desruisseaux wrote:
> > >
> > > > 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?
> > >
> > > 1- The CUA doesn't "modify results", it modifies components
> > >    stored in the CS.
> >
> > The 'results' are a valid VCAR with a BOGUS CARID.
> > 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.

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).
 
> > > 2- The means used by the CUA to come up with a replacement
> > >    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.
> 
> 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).

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.


> > > 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!
> >
> > 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.
> 
> 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!

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.

> > > 4- CUA MAY specify EXPAND:TRUE when they are querying
> > >    VCAR components for evaluation purposes.
> >
> > 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.

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.

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

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.

> >
> > If no - then it needs to be marked DECREED? Because for
> > 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.

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."

> 
> > 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 current 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.
> 
> 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?

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.

begin:vcard 
n:Royer;Doug
tel;pager:pager@xxxxxxxxx
tel;cell:208-520-4044
tel;fax:866-594-8574
tel;work:866-594-8574
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:INET-Consulting LLC <http://INET-Consulting.com
adr:;;;;;;
version:2.1
email;internet:Doug@xxxxxxxxx
title:Chief Executive Manager
x-mozilla-cpt:;64
fn:Doug Royer
end:vcard