Re: Groups revisited

[rans@xxxxxxxxxxxx (Richard Shusterman)]

Bruce_Kahn@xxxxxxxx wrote:

> 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,
> "CAPEditors@xxxxxxxxxxxxxxxxxxxxxx".  This is in effect a group UPN since
> all 5 of them share it.

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?

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

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.

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

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.

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

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