Steve, thanks that makes it a lot clearer. I have, though, some comments: A) Regarding the security credentials ===================================== The proposal makes sense, but I would like to extend it and slightly change it as follows. 1. We should consider the DataEPRs personalised EPRs, i.e. minted for exactly one client. That client MAY re-use this DataEPR (whether for the [source] or the [sink] in a DMI call, or otherwise) but SHOULD NOT (or MUST NOT?) pass it along to other entities in a Grid for their use. 2. The element "dmi:Credential" suggests only one credential allowed, even though the contents is defined as "<xs:any/>*", i.e. zero or more child elements may occur. I instead propose to change "dmi:Credential" as follows (in pseudo schema): <dmi:Credentials> <xs:any namespace="##other">* <dmi:Credentials> This then would serve as a more generic credentials container, and proper identification and tagging of each of the credentials if any are left to be specified by either profiles, or implementations. This would even all ow for cross security-framework implementations to insert credentials for GridFTP in a GSI implementation, and (in the future, credentials for GridFRP in, say, a UNICORE security framework. Good data transfer protocols allow for more than one security framework; GridFTP is just not yet there. At the same time this would allow for both the future [source | sink] service *and* the DMI client to insert credentials into this section. It seems a bit awkward to me that the [source | sink] service should insert the client's (user's?) security credentials into the DataEPR. It should be *both*, to serve the following use cases. As the DataEPRs have an identical structure for both source and sink the use cases mention only one DataEPR for brevity: - The client uses a command line tool and forges the DataEPR. The command line client, in the process of creating the DataEPRs uses security information taken from the context (e.g. command line parameters, linked-in security store, etc. - The client (or user) obtains the DataEPR from the source service. The source service adds a username/password credential in a reckognised format to the dmi:Credentials element, indicating that no more information is necessary (this is done within the reckognised format out of scope for OGSA-DMI). The client then MAY add the user's identification credentials to communicate on who's behalf it is operating. - The client (or user) obtains the DataEPR from the source service. The source service adds challenge information to the dmi:Credentials element of the minted DataEPR (e.g. a SecurID challenge). The client then MAY add the user's identification credentials to communicate on who's behalf it is operating. The client MUST add the proper challenge response to the dmi:Credentials section to successfully be authorized to access the data. The details how the security stuff is actually handled can be left completely implementation specific, or handled in profiles on OGSA-DMI. But I think OGSA-DMI should indicate that it can be more than one set of credentials passed in. Actually, come to think of it, really advanced implementations may use DataEPRs to the extreme: Given that advanced implementations support several security frameworks (say, Globus GSI, UNICORE style Explicit Trust Delegation, and Windows Active Directory) equally available for some data transfer protocols (e.g. GridFTP, HTTP, SRB), then they could put the security credentials that are shared between two different data transfer protocols outside the dmi:Credentials section, and just add XML links (using for example xs:ID and xs:IDREF) from within the dmi:Credentials section pointing to the external credential information. And all that is compliant to the OGSA-DMI specification while greatly saving from duplicating information in the DataEPRs metadata section. But that is probably just my thoughts gone wild... B) Editorial nag regarding authors list ======================================= You are beyond doubt an important author of this spec, and as such ought to be mentioned as such. Chapter 7 lists at the moment 4 people, all of which I believe are the authors of this specification. GFSG, however, did not intend to have the names of the authors in the document headers. Instead, the document (and page) header was intended to contain the names of those people who volunteer for permanent stewardship of the document. That list of names can be a subset of the authors, but can also be a different list of names. GFSG originally thought of 2 people at max, but left the backdoor open for more *if there are compelling reasons*. I hence propose that we keep that list to two, at max 3 people, and strengthen the statement in chapter 7 regarding the authors - and other contributors if any. But I am not terminally glued to this and very open to discussions (I mainly want to avoid stupid nags just like this in PC). Cheers, Michel