Well, just to be clear on my purpose in mailing the group, it wasn't to ask the group to put username/password into the URI or to specify a format for putting it into the URI. My concern was that the HPCP specification explicitly prohibits an HPCP File Extension compliant endpoint from accepting the username/password in the URI. While I agree in principle that username/password in the URI is unsafe, I don't think that the HPCP Profile should restrict or limit another valid implementation from using it that way. Can't the HPCP simply specify what the File Extensions add as specification and remain silent on other ways of doing it? -Mark On Sun, 2008-06-29 at 22:53 -0700, Steven Newhouse wrote:
Which is why we decided not to support the credential embedded in the URI and to put in an extensible Credential element placed in the JSDL document for each stage in/out element.
Steven
-----Original Message----- From: Donal K. Fellows [mailto:donal.k.fellows@manchester.ac.uk] Sent: Sunday, June 29, 2008 4:38 PM To: Steven Newhouse Cc: ogsa-hpcp-wg@ogf.org Subject: Re: [ogsa-hpcp-wg] [Fwd: FIle Staging Extensions Comment]
Steven Newhouse wrote:
It was discussed in the working group. My recollection was that there was no defined 'standard' mechanism for embedding a username and password into an scp uri. Therefore we did not feel happy specifying one.
I'd have thought in that case that going with the "generic URI" format for usernames and passwords would be the right thing then, leading to:
scp://user:pass@host.com/path/to/file
This will be pretty easy to implement (stripping the password out and passing it to the copier correctly won't be a big challenge). However, reading http://tools.ietf.org/html/rfc3986 (the current definition of the generic URI format) leads to a problem with this, in that the embedding of passwords here is massively unsafe and leads to a range of troubles (including, but not limited to, making the document highly security-sensitive). I think we already knew that! (On the plus side, I don't think we need to worry so much about the issues documented in section 7.6 of that RFC for now; JSDL isn't a user-focussed format...)
What we really need here is proper security delegation. That's the only solution which is actually of any real long-term good. This is just a (necessary) band-aid.
Donal.
-- ogsa-hpcp-wg mailing list ogsa-hpcp-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg