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, "CAPEditors@xxxxxxxxxxxxxxxxxxxxxx". 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: 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...
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature