[ogsa-dmi-wg] New version

[Michel Drescher]

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://www.ogf.org/pipermail/ogsa-dmi-wg/attachments/20070823/b57db6f8/attachment.pgp