I don't disagree that user credentials will be important for many jobs. However, I disagree that a type and semantics-free UserCredential field, as in the current draft, actually helps. I think a consumer of a JSDL document needs to know two things to make use of credentials: 1) what is it, and 2) what is it for. I think it is wishful thinking to say there is one generic user credential category and the consumer can divine the rest from the value itself. If this is so, we might as well put this expressive value in the xsd:any##other slot as an extension (understood by some, but not all, consumers). For example, in WS-GRAM for GT4, we do not pass around credentials per se, but we do pass around references to credentials (the actual credentials are moved ahead of time by out-of-band means relative to WS-GRAM). Because each of these references is of the same type (and referring to the same type of credential: our GSI proxies), we have separate fields in the WS-GRAM job language to designate the purpose of each one: one to put in the job's environment (as a file), one for WS-GRAM to use when invoking our RFT file transfer service, and a third to pass through (by reference) to the RFT service itself (which it then uses to authenticate with GridFTP). We would have to use these wrappers in the JSDL transliteration, since "user credentials" is too abstract to actually convey the different meanings we have. I suspect that any meaningful "pass through" would have to do the same thing---designate _which_ target mechanism to pass the values to. It wouldn't help much if a JSDL consumer "passed" a Kerberos ticket in the file where we expect GSI proxies, or vice versa. karl -- Karl Czajkowski karlcz@univa.com