Having credentials is not enough. A site might want to have control of the way the environment is setup. Consider the following: A user might be a member of a VO that has access to your site. At the same time this user has a local account on your site. When this user want to use some of the resources of the site, either it is done on the account of the VO or as a local user of that system. A site has a choice now. When a user with a local account wants to make use of the resources, a site can decide that the user can use the resources under his/her own account regardless of any VO he/she is a member of. Of course a site might also decide that even though a user has a local account, he/she needs to use the VO affiliation first.
For this reason, each site has a set of policies. These policies, together with the credentials, determine the environment of the user. The policy rules are described in a configuration file. This configuration file is composed of plain text to make it readable by humans and editable by a wide range of editors. Another important fact is the readability of the file. This should be is as intuitive as possible. If the description of policies is too difficult, errors are easily made. Mistakes can lead to assigning resources to a person which has no right to that particular resource. It would be embarrassing to send the billing to the wrong VO. Clearly, this must be prevented as much as possible. By trying to keep the language a simple as possible, it is our believe that these kinds of mistakes should be kept to a minimum.
Also, by not over complicating the structure of the configuration file, graphical user interfaces can be easily created. Thus, further limiting unwanted mistakes. This is, however, not the first goal at this stage of development, but it might be desirable once the subsystem is in use by less experienced users.
0