I wanted to add that I still find the credential parts of JSDL confusing... my intuition is that this is not something that can be usefully abstracted: by the time you wave away specific mechanisms for a security environment, the field is no longer useful for mapping the real domain-specific info. I would rather see JSDL treat this as out of scope, at least for 1.0, and make sure the extensibility can allow communities to embed their own credential management constructs as needed. I think we need to admit structured domain-specific elements rather than ever punting to a string type for this kind of information. This is not to say that there are not reasonable things for JSDL to do w/ identity such as the selection of user and group IDs. These are not credentials, but part of the parameterization of the job "container" for a wide range of job types; there are not security risks with this, because as Donal said before, the operational environment that uses JSDL is responsible for making authorization decisions. This is analogous to GRAM allowing job requests to select a local user account: whether this is allowed or not is dependent on the authenticated PKI context of the request and the local site "mapping" policies; the job request is not blindly implemented. karl -- Karl Czajkowski karlcz@univa.com