I'm also in agreement with this position. The recommendation for interop purposes is to put username/password in the Credential element. The HPCP specs should not encourage or support other mechanisms as compliant options. /Blair
-----Original Message----- From: ogsa-hpcp-wg-bounces@ogf.org [mailto:ogsa-hpcp-wg- bounces@ogf.org] On Behalf Of Marty Humphrey Sent: Thursday, July 03, 2008 6:24 AM To: 'Christopher Smith'; 'Mark Morgan'; Steven Newhouse Cc: ogsa-hpcp-wg@ogf.org Subject: Re: [ogsa-hpcp-wg] [Fwd: FIle Staging Extensions Comment]
I agree with this -- again, we didn't want the compliant implementation to need to support TWO options here, and in addition be faced with the confusion regarding a message that contains BOTH. So we think restricting the URI is a good thing.
-----Original Message----- From: ogsa-hpcp-wg-bounces@ogf.org [mailto:ogsa-hpcp-wg- bounces@ogf.org] On Behalf Of Christopher Smith Sent: Monday, June 30, 2008 11:08 AM To: Mark Morgan; Steven Newhouse Cc: ogsa-hpcp-wg@ogf.org Subject: Re: [ogsa-hpcp-wg] [Fwd: FIle Staging Extensions Comment]
I believe one of the motivating factors for leaving it out was to deal with the ambiguity of having embedded username/password in potential conflict with the "Credential" element. We decided to say that if you want to pass username and password, do it in the Credential element. Otherwise you get in a situation where the implementation doesn't know which username/password to use.
Simplify in order to aid interoperability was the guiding principal. I, for one, stick with the original reasoning and think restricting the URI is a good idea.
-- Chris
On 30/6/08 06:20, "Mark Morgan" <mmm2a@virginia.edu> wrote:
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
Which is why we decided not to support the credential embedded in
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
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"
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
On Sun, 2008-06-29 at 22:53 -0700, Steven Newhouse wrote: the URI and there format 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
-- ogsa-hpcp-wg mailing list ogsa-hpcp-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg
-- ogsa-hpcp-wg mailing list ogsa-hpcp-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg
-- ogsa-hpcp-wg mailing list ogsa-hpcp-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg