[ogsa-hpcp-wg] [Fwd: FIle Staging Extensions Comment]

[Blair Dillaway]

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 at ogf.org [mailto:ogsa-hpcp-wg-
> bounces at 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 at 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 at ogf.org [mailto:ogsa-hpcp-wg-
> bounces at ogf.org] On
> Behalf Of Christopher Smith
> Sent: Monday, June 30, 2008 11:08 AM
> To: Mark Morgan; Steven Newhouse
> Cc: ogsa-hpcp-wg at 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 at 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
> >
> > 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 at manchester.ac.uk]
> >>> Sent: Sunday, June 29, 2008 4:38 PM
> >>> To: Steven Newhouse
> >>> Cc: ogsa-hpcp-wg at 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 at ogf.org
> >>   http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg
> >
> > --
> >   ogsa-hpcp-wg mailing list
> >   ogsa-hpcp-wg at ogf.org
> >   http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg
>
> --
>   ogsa-hpcp-wg mailing list
>   ogsa-hpcp-wg at ogf.org
>   http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg
>
> --
>   ogsa-hpcp-wg mailing list
>   ogsa-hpcp-wg at ogf.org
>   http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg