The concrete use case I have from Globus is to indicate under which POSIX username a job should be executed. I see group (actually, default or primary group) as a reasonable extension of the concept, though we do not do that today. This use case is job configuration details, just like POSIX limits, environment variables, etc. It is important in situations where there is not a one-to-one mapping of global user identity (PKI subject) to local accounts for the GRAM service to apply, e.g. when a user has several role-specific accounts or temporary "scratch" accounts. Of course, such configuration values are subject to authorization checks in practice. I am not clear on whether this is the intended purpose of the existing user and group fields in the User section, but if it is not then I am not clear on what it is for at all... I admit my bias is towards thinking of the use of JSDL in distributed protocols like GRAM. I guess if we were to use it in the local "adapter" interface between the GRAM service and the local scheduler scripts, we might have a use for specifying the authenticated user name, which for GRAM would be a PKI subject name. This makes sense because the adapter scripts inherently trust GRAM; GRAM would reject the presence of such a field in the over-the-wire transmission of JSDL, since the user identification comes from the binding-level security mechanisms. I can see this kind of info belonging in a User section for the adapter case, but I still need the POSIX username in the executable section. karl -- Karl Czajkowski karlcz@univa.com