Subject: Re: W-19 - open item - can we defer it?

From: Doug Royer <[email-masked]>
Date: Tue, 11 Jan 2000 16:54:29 -0800

[email-masked] wrote:
> 
> Doug proposed:
> >A VCAR can specify a list of users:
> >
> >BEGIN:VCAR
> >CARID:Permisssions for group 'A'
> >GRANT:UPN=<user1>...
> >GRANT:UPN=<user2>...
> >END:VCAR
> 
> Sure it can.  However this is the case of the statically exploded group of
> users (new term, add to your vocabs please!).  It will not help me when I have
> a new user that I want to add to the  the original groups of users that you
> exploded. 
> ...
> Bruce
> PS: Who here honestly would stand up in front of a User Group meeting or
> conference and _honestly_ say that doing dynamic groups of users expansion was
> too hard to do and that static expansion is really the better choice??  ( Ill
> be in the front row of that talk! ;^) )

Okay - now you wish to administer the VCAR for a user-list(group). If it
is not expanded by the CS how will you ever find who is on the list?
Or as some have expressed, how to find out if you have permission to
do something.

I don't see any difference between a VCAR for one or many (huge) number of
users. As in:

	(1) They have access or not to whatever the VCAR specifies.

	(2) They have read access to the VCAR or not.

The only issue as I see it is how do you administer the list
and MUST or MAY it be expanded dynamically to a CUA.

A specific implementation my allow dynamic lists (LDAP or whatever).
There still needs to be an interoperable way to find out who is on a
dynamic list. That can be done with or without CAP (LDAP Tool for example).

I assert that if you are a CAP client:

	(A) And you have access to read the VCAR, then the expansion
	    must be possible (Assuming you have permission and it is
	    not a violation of site administrative policy) Otherwise you
	    would be requiring all CUAs to understand all dynamic list
	    implementations - Not possible.

	    preposal:

		(A.1) If the CS is unable or unwilling to expand the
		      list, OR the CS administrator has elected not to
		      allow list expansion:

			Then return as the VCAR something like this IF
			they happen to be a MEMBER of the LIST and
			were GRANTed or DENYed access the the CS would
			dynamicly create a wire VCAR into:

				BEGIN:VCAR
				CARID:Permisssions for group 'A'
				GRANT;MEMBER=<group-name>:< Querying-CU's-UPN>
				END:VCAR

			Or:

				BEGIN:VCAR
				CARID:Permisssions for group 'A'
				DENY;MEMBER=<group-name>:< Querying-CU's-UPN>
				END:VCAR

			Because ether way there would have to be a unique
			ID for the group name and they simply would or would
			not have access to the resource specified by
			that VCAR.

			Then a CUA WOULD be able to determine in advance
			if the CU had permission for an operation without
			dynamic list expansion.  Determinable by a MEMBER=GROUP
			parameter to GRANT or DENY.
		
		(A.2) If the CS can show some CUA the list, then it 
		      could be sent as:

				BEGIN:VCAR
				CARID:Permisssions for group 'A'
				GRANT;GROUP=<foogroup>:UPN=<...>
				...
				DENY;GROUP=<foogroup>:UPN=<...>
				...
				END:VCAR

		OR

				As in (A.1)

	(B) If you do NOT have access to read the VCAR, the answer of
	    how to show them is irrelevant.

I think this addresses all of the issues. I do not think that we should
define a way to administer user-group-lists. And I do not think that
we can mandate that CUA's or CS's  MUST have user-group-lists.
We could mandate that a CUA understand what a GROUP= parameter in
a GRANT or DENY means there may be more users that are not determinable
to the CUA.