Re: URI scheme listing for httpsy

On Sunday 17 August 2003 12:41, Larry Masinter wrote:
> I think I get the idea,

Great.

> but there are some confusing parts of your draft.

That's certainly possible. You have more experience writing
specifications. I appreciate your assistance in making the httpsy
specification conform to expectations.

> You say that 'the host is merely a hint',
> but it isn't optional, and there's no way to locate
> the resource without the host. So this isn't consistent
> with the ordinary technical definition of a 'hint'.

The host isn't optional for the URI producer, but it is optional
for the URI consumer. The URI consumer is free to ignore the host
hint.

For example, the java.net.URL implementation that I have provided
will ignore the host hint if it already has an open connection
with a succesfully authenticated server. The resource request will
be sent to the already authenticated server, instead of using the
host hint to again locate the server.

If you wish to propose alternate text for specifying this
behaviour, or any other in the specification, please do so. Your
input is welcome.

> The draft, as written, looks like it is modifying the
> https scheme, taking over all uses of https with
> a '*' in the 'userinfo' field.

For a 'userinfo' field that starts with a '*', and only for
software that implements the HTTPSY protocol. Other software is
of course unaffected. I don't anticipate this causing any
problems. Do you know of any potential problems?

> With HTTPS, you say
> 'The *key_id@ portion of the URL MUST be ignored',
> but this sounds like you're making normative change
> to how the https URL is supposed to work. I'm not
> sure why you need to do that.

I am not intending to make a normative change to the https URL
syntax. I am specifying the conditions required to make the https
*-subset work.

The MUST means that the specification of the https *-subset is
broken if an https client assigns a conflicting meaning to the
*key_id@ portion of the URL.  According to RFC 1738, an https
client cannot do this. The https client MUST treat the *key_id as
a username. For an https *-subset URL, this username will never
get used. Therefore, the MUST in the https *-subset specification
is compatible with the constraints of RFC 1738 that govern
existing https URLs.

Again, please feel free to suggest alternate text.

> Suppose you do intend to take over a chunk of the
> 'userinfo' space. Consider using something more
> distinctive than '*', like '*waterken:<key>*'

Why? The '*' is already very distinctive. I am not aware of any
conflicts. Your suggested syntax does not seem realistic for a
widely deployed URL technology.

> I think you need to work out the deployment and
> upgrade steps more clearly.

Ok. Is this something that belongs in the protocol spec though?
Wouldn't a supporting document be more appropriate?

> Why do you ever need 'httpsy'?

The https *-subset URL scheme allows you to run the HTTPSY
authentication protocol in tandem with the existing PKI. This
helps with deployment of the new protocol, but does not eliminate
any costs. The point of the HTTPSY protocol is to eliminate the
costs associated with using the PKI. When you stop using the PKI,
you have to switch to the httpsy URL scheme so that clients know
that they must not rely on the PKI authentication protocol.

For example, a future resource may be accessible through the URL:

httpsy://*asdfjklqweorugnasdfasduifw@yurl.net/

The identified resource is using yurl.net as a redirection
service.  The resource host does not trust the owner of the
yurl.net domain name to *be* the identified resource, only to help
locate the identified resource. Were a client to use the PKI to
authenticate the server, the client would be authenticating the
wrong server. The client would be authenticating the yurl.net
server, not the server identified by the URL producer.

In short the httpsy scheme is needed to create the MUST constraint
for using the HTTPSY protocol. It is not possible to create this
MUST constraint if the specification is only an add-on to an
existing URL scheme.

> Anyone starting deployment would
> never use a 'httpsy' URI because so few clients
> would know what to do with it. So web sites might
> start using the compatible form (using http: or
> https:), but, since that works well enough, why
> would anyone ever deploy something that understands
> 'httpsy'?

Notice that the only difference between supporting the https
*-subset and httpsy, is the change in URL scheme name.  Everything
else is identical. I doubt anyone would implement the first and
choose to not recognize the second.

The motivation for adding the httpsy hook is to realize the cost
savings that come from eliminating use of the PKI.

> In general, the uses of MUST and SHOULD in your
> document aren't conventional; e.g., when you say
> 'The address of a nameserver SHOULD be much more
> constant than that of a server', it's hard to know
> for whom this language should be normative.

This constraint is normative for the URL producer. Implementors of
client software must be able to rely on using the host hint to
locate the identified server. The URL producer SHOULD therefore
ensure that the host hint remains useful.

I hope you will find the time to help clarify the httpsy
specification.

Tyler

-- 
The union of REST and capability-based security:
http://www.waterken.com/dev/Web/

Received on Sunday, 17 August 2003 19:21:44 UTC