Re: secure URIs

At 10:51 AM 5/2/2003 +0100, Clive D.W. Feather wrote:


>[For some reason this didn't go to the list. Trevor, do you want to post
>your reply to it, or do you want me to do so?]
>
>Trevor Perrin said:
> >> Bitter experience says that it's always better to make the scheme as wide
> >> and extensible as possible. In particular, "why would you want that?" is
> >> almost a guaranteed recipe for later regrets.
> >
> > If "secure" is restricted to crypto metadata, you could always define 
> other
> > schemes for different metadata types:
> >
> > language:http://whatever.com:french
>
>You could, but why bother? That's gross special-casing when there's a much
>more general approach.


You're right - if you want to attach metadata like that, a single "meta" 
scheme is the way to go.

However the crypto data we're considering (document hashes, key/cert 
fingerprints, key/cert URLs) aren't what I think of as metadata (they don't 
describe the resource, they control how the resource is retrieved).  And 
there's costs to too much generality too.  So I'm going to suggest a 
"secure" scheme just for crypto data, with a "meta" scheme as a separate 
thing (if a case can indeed be made for it).

Reasons:

- Every secure URL has a minimum semantics, so these URLs should be easily 
recognizable.

Every secure URL lets the resolver ensure that the resource he retrieves is 
what the creator of the URL intended (whether through authenticating the 
resource to a hash, or authenticating the server to a fingerprint).

So if someone sends me an email, and I see a URL starting with "secure:", 
then I don't have to read the gobbledygook at the end to know that I can 
paste this URL into my browser, and retrieve an authenticated view of the 
resource.  And if I do this and my browser doesn't recognize the crypto 
data, it can say "Warning: this link has security data attached, but I was 
unable to process it.  Do you want to proceed anyway?"

If crypto data was transported within a "meta" scheme, it would've been 
harder to recognize that this is a secure URL (I'd have to look at the end, 
and recognize that "sha512" is crypto data), and my browser wouldn't have 
been able to give a security-specific error message.


- A general "meta" scheme would probably be more complex than a "secure" 
scheme.

For example, since a "meta" scheme should be extensible to different types, 
it should provide for namespace qualification of metadata attributes.  If 
the "meta" scheme allows data that change the interpretation of the 
resource, then the "meta" scheme would need a criticality flag to indicate 
that understanding certain metadata is necessary to resolving the URL (or 
might one metadata attribute be critical to understanding another?).  Does 
ordering matter?

You'd need to collect a greater range of metadata types and examine their 
specifics to determine if other requirements are needed, and that's an 
effort in itself.  And a "meta" scheme will need to consider its relation 
to other metadata efforts (like RDF/Semantic Web).  Would it be competing 
with them?  Complementary?  Would they want to use it to transport their 
own statements?  If so, what requirements would that add?

And since the scope of the effort would be wider, I'd worry it would take 
longer to bring all the communities involved to agreement (this is just a 
tactical concern about the difficulties of producing/rolling-out a 
standard, but still..).


- A secure URL could be easily used within a "meta" scheme:

meta:<secure-URI>:<metadata>

So doing something simple and recognizable for secure URIs doesn't preclude 
a "meta" scheme for more general metadata.


Comments?  Counter-arguments? (or if people agree, it might be interesting 
to discuss the "meta" scheme in a separate thread..  It would be 
particularly interesting to hear what people with more knowledge of 
Semantic Web or other metadata projects think)...

Trevor

Received on Tuesday, 6 May 2003 21:28:34 UTC