Re: Groups revisited

[Bruce_Kahn@xxxxxxxx]

Richard 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?

When I AUTHENTICATE with my CS, the credentialling process will result in 
1 or more UPNs being 'spat out' if the process works.  Lets say that when 
Frank AUTHENTICATEs with his CS, it (his CS thanks to the authentication 
mechanism) says that the pair of UPNs Frank_Dawson@xxxxxxxxx and 
CAPEditors@xxxxxxxxxxxxxxxxxxxxxx are 'valid' identities for Frank.  He 
can use them as part of VCARs or wherever else we allow UPNs. 

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

The CS _really_ should keep all the UPNs that are spat out for VCAR 
comparison, etc.  That way, if there is a VCAR on a paricular event in the 
calendar that has a VCAR that only allows 
CAPEditors@xxxxxxxxxxxxxxxxxxxxxx to read or edit it then Frank should be 
able to access that entry.  Just because Franks "primary" (ugh, for lack 
of a better description so do not take literally) UPN is 
Frank_Dawson@xxxxxxxxx does not mean that he has to do nasty things like 
switching identities to be able to access an entry that does have 
CAPEditors@xxxxxxxxxxxxxxxxxxxxxx on the VCAR.  The CS should do this 
equivalence for him!

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

Smack the group UPN creator up side the head.  Groups are much more useful 
if their are descriptive than if they are just mangled sequences of 
seemingly random junk.  Sometimes they are not easily distinguished from 
that of a single CU (ie: postmaster@xxxxxxxxx is probably shared among a 
couple folks even though it could be just 1 person). 

Im still a big KISS advocate and Im not sure we need/want to have the CS 
do group expansion by request.  That sounds like a directory issue really 
rather than a C&S one.  Just as a CUA would probably do some kind of 
lookup (ie: LDAP, etc) on Frank_Dawson@xxxxxxxxx to get some info Frank, 
the same can and probably should be done by the CUA for the other UPN.

In addition, I think the CS should fully unwind nested groups for the 
fairly obvious reason that ANY nested group could be on a VCAR.  As such 
as long as Frank is a member of a nested group he should be granted/denied 
access accordingly.

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

Personal address books cannot be used by the CS to enforce or expand group 
UPNs during AUTHENTICATion.  Besides being a BIG security hole, its not 
feasible to even consider HOW the CS could safely get the info from the 
CUA and really trust it..  I dont want to murky the waters by talking 
about local replicas of the CSs address book (or partial replicas, etc). 
Thats OOB for CAP I think.  For the CU to create their own group UPNs that 
the CS can use, it would have to be done in such a way that the CS can 
trust the data (ie: via read/write control to a shared LDAP server, etc). 
We can dive on some of the nitty gritty issues later but Im trying to see 
if the higher level view/logic I posted originally is accurate...

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

We are of similar thought I think but you are doing the expansion in a 
different way then I proposed.  If the CS determines ALL the UPNs I am 
synonymous with when I AUTHENTICATE then it does not have to expaned EVERY 
VCAR on every ACCESS to try and find a match for my 'primary' (sic.) UPN. 
Its much much cheaper to take the hit up front than for every 
request/response that needs to be done.  As long as ANY UPN in my list of 
identities matches the VCARs then that VCAR is applied to me.  That only 
drawback is that a change to a group UPN wont take effect until I 
reAUTHENTICATE.  Typically though this is not such a big deal and can be 
handled by some good upfront CS architecture for handling change 
notifications.

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

Argh, a step backwards in agreement.  WAAY back in Montreal we agreed that 
the authentication process could generate > 1 UPN for a set of 
credentials.  We never precluded that all of those UPNs must be unique for 
a CU.  If its not unique per CU then it in effect is a group UPN.

Im claiming that groups can be easily handled by this ability to have > 1 
UPN generated when I AUTHENTICATE with the CS and that is something that 
all CS vendors will have to deal with.  Im NOT a big fan of bloating CAP 
even more by having the CS act as a UPN directory server of sorts as it 
just deters vendors from making CS implementations. 

Just how do were you (collectively now) envissioning that the CS would use 
the other UPNs that are generated as part of the certification process?? 
Are they to be ignored?  If all CSs must generate the same list of UPNs 
for a given set of credentials then what is the big deal in the CS using 
them to evaluate VCARs, etc later one?

I think that in an effort to 'add groups' into CAP we are making this 
issue overly complex.  It is not that difficult for a CS to compare a list 
of UPNs (for an authenticated CU) against those on VCARs instead of simply 
comparing 1 UPN.  Or am I missing some argument somewhere that says groups 
have to be a complex beast??

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

Ok this may be bass ackwards but Ill try to rephrase my idea in as simple 
terms as Im able at this time of day:

Given:
1: The AUTHENTICATion process may result in > 1 UPN being generated for a 
given set of credentials and
2: Not all UPNs are 100% unique per CU

That:
1: It is possible to have a 'group' UPN  generated as one of a CUs UPNs 
when they AUTHENTICATE and 
2: A CS should be able to match ANY of the UPNs generated during 
authentication in a normal UPN check (ie: in VCAR evaluation)

Therefore:
1: This 'group' UPN can be used anywhere a UPN is normally used (ie: VCAR) 
and
2: No extra or overly complex extra mechanisms are needed in CAP to 
distinguish a 'group' UPN from an 'non-group' UPN and
3: We do not need to distingush beteen 'group' and 'non-group' UPN flavors 
anymore.

Does this help clarify my original posting??

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@xxxxxxxx
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...