Subject: Groups revisited

From: [email-masked]
Date: Tue, 15 Feb 2000 10:54:34 -0500

Ive been more than a little busy lately to keep up w/all the threads going 
on but I have been chewing on the issue of groups in CAP and how we 
can/should be dealing with them.  After going back to the basics a bit I 
think we do not really need to do much, if any, extra effort to have them. 
 Here is my reasoning:

When a CU authenticates to the CS the credentialling system will output a 
series of UPNs for that mechanism and set of credentials.  So what is to 
prevent that authentication mechanism from including a UPN that both 
Frank, Steve, Doug, Pat and Alex have that is, say, 
"[email-masked]".  This is in effect a group UPN since 
all 5 of them share it. 

The UPN can then be used as part of a VCAR to give them write access to a 
particular calendar or entry.  When any of them try to modify the 
particular calendar or entry the CS can check their list of UPNs to see if 
they have the proper rights.

The real work now shifts from doing some evaluation for every access 
(where some previous ideas were seemingly heading) to being handled once 
at AUTHENTICATE time.  This shift means that we need to be very precise in 
how we spec out our authentication mechanisms so that every vendor who 
implements it will generate the correct set of UPNs.  This task may be 
non-trivial but it simplifies MUCH of the later work.

Ive tried to be as clear as I can describing my train of thought w/o being 
too rambling or circumspect.  After a second pass at it I do not see any 
glaring logic flaws so I thought Id propose this to the group to see if 
its off in left field or if we just overlooked something so simple by 
jumping to more complex solutions...

Bruce
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: [email-masked] (Richard Shusterman)
Date: Wed, 16 Feb 2000 11:28:43 -0800

> "[email-masked]".  This is in effect a group UPN since

I don't think I understand. Are you saying that the CS would have to search
thru it's directory and find all the groups that reference the UPN that your CU
is presenting for you? I guess it would then keep these group references for
VCAR evaluation and if asked, return these group references to the CU so that
it could use them for VAR create/edit? Since group names are not usually that
descriptive, the CU should also be able to show the user the list of UPNs in a
group. And, what if the CU wanted to use one of these groups for populating
it's attendee list?

> they have the proper rights.

This assumes that your set of group's matches the set of group's for another
user. This may not be the case for personal address book groups.

As I see it, the CS must evaluate all VCARs associated with a particular
calendar, expanding groups down to their individual UPN's. While it's doing
this evaluation/expansion, it will try to match your UPN with a VCAR until you
are allowed access or it runs out of VCARs to evaluate/expand. This needs to be
done dynamically to ensure that the CS picks up any new UPNs that are added to
a group.

> non-trivial but it simplifies MUCH of the later work.

I'm not sure I like this approach. This forces CS vendors to support groups.
The approach presented by the Boston draft additions makes group support
optional, i.e., the CS must still respond to EXPAND/LOOKUP but if it doesn't
support groups, it would always return the passed-in CSID or UPN.

> jumping to more complex solutions...

On first thought, this approach seems more complex, especially for the CS. But
maybe, I just need to hear more...