Subject: Re: Groups revisited

From: [email-masked]
Date: Wed, 16 Feb 2000 16:14:31 -0500

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,
>> "[email-masked]".  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 [email-masked] and 
[email-masked] 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 
[email-masked] 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 
[email-masked] does not mean that he has to do nasty things like 
switching identities to be able to access an entry that does have 
[email-masked] 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: [email-masked] 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 [email-masked] 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: [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, 23 Feb 2000 12:09:52 -0800

Bruce,

Sorry I took so long in responding. Some responses below:

[email-masked] wrote:

> 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
> [email-masked] and [email-masked]
> are 'valid' identities for Frank. He can use them as part of VCARs or
> wherever else we allow UPNs.

How does Frank get his list of UPNs? One of the new CAP commands
that we came up with in Boston to solve this problem was LOOKUP
(a proposal was recently made to rename this to UPNEXPAND). Or,
are you suggesting that as part of the AUTHENTICATE response, these
UPNs are returned?

> comparison, etc.  That way, if there is a VCAR on a paricular event
> in the calendar that has a VCAR that only allows
> [email-masked] to read or edit it then Frank should
> be able to access that entry.  Just because Franks "primary" (ugh, for lack
> [email-masked] does not mean that he has to do nasty things
> like switching identities to be able to access an entry that does have
> [email-masked] on the VCAR.  The CS should do
> this equivalence for him!

I agree. That's why we also agreed in Boston to remove the IDENTIFY
command (which somehow still lives in the CAP draft - I will ask the
editors to remove it) since it's not needed.

> 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

Since group names are not always descriptive, hence the need again for
the LOOKUP (or UPNEXPAND) command. BTW, if the CS chooses not
to support group expansion, it can simply return the same UPN passed in
by this command.

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

Whether a CS supports groups and whether a CS unwinds nested groups is
an implementation issue. If the CS supports groups (as in your VCAR example),
it might as well make this information available to the CUA via the LOOKUP
(or UPNEXPAND) command.

> 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
> Thats
> OOB for CAP I think.  For the CU to create their own group UPNs that

Depends on where the personal address books are stored ... maybe they're on
the CS? In any case, this is implementation specific.

> 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 reAUTHENTICATE.  Typically though this
> is not such a big deal and can be handled by some good up front CS
> architecture for handling change notifications.

Implementation specific.

> Argh, a step backwards in agreement.  WAAY back in Montreal we
> agreed that the authentication process could generate > 1 UPN for a set of

Agreed.

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

The CS is not required to be a UPN directory. However, if we agree that
it's a good thing to put group UPNs in CAP, then we need definitions and
commands to allow a CS to share this information with a CUA. A CUA
should not assume that it's CS supports groups. Perhaps, it would help
if we added a CAPABILITY response from the CS that can tell the CUA
exactly what level of group support is available in this CS, e.g., group UPNs
are allowed, nested groups are expanded, etc.

> them to evaluate VCARs, etc later one?

I think the AUTHENTICATE process has to allow a CS to ignore multiple
UPNs just like a CS should be allowed to ignore group UPNs. Not every
CS vendor will want to support these features.

> 2: Not all UPNs are 100% unique per CU

Agreed.

> authentication in a normal UPN check (ie: in VCAR evaluation)

Agreed, especially the "should" part.

> 3: We do not need to distingush beteen 'group' and 'non-group' UPN flavors

Agreed. I think this is what we came up with in Boston and is now reflected in
the
CAP draft.

Richard

---

From: Doug Royer <[email-masked]>
Date: Sun, 27 Feb 2000 11:02:32 -0800

> editors to remove it) since it's not needed.

I have seen NO meeting notes that suggest this. And I have not seen this topic
discussed on this WG.

IDENTIFY is still in the CAP draft.

How do you act on behaif of someone? That was the purpose of IDENTIFY.
I had said in the past that you set the SEND-BY paramater in the
ORGANIZER property. Is that how you do it?

I understand the text for which you replied, but IDENTIFY had another
purpose. And that was (I am Doug, doing this for Steve).

So are you saying, I login as Doug and get back UPN:Doug and UPN:Steve?

What if I want to access Steve's calendar, whois UPN do I use?
How do I specifiy it at run time?

If I use UPN:Doug then there would be an VCAR that allows UPN:Doug 
some access.  If I use UPN:Steve then how would it know that I
was not Steve and grant me more permission than Steve wanted?

If I do not use UPN:Steve, then why do I get it back?

-Doug