ACTION-278 Hiding metadata for security reasons

Regarding ACTION-278, here is preliminary draft text to add to the end
of section
2.7 "Hiding metadata for security reasons" of TAG finding "The use of
Metadata in URIs" [2]

Criticism welcome; I'm expecting I'll have to substantially revise in
the face of
the wisdom to be precipitated.

<snip>

In special circumstances where URIs are adequately protected for the
application in question, it may be safe to create URIs that carry
sensitive metadata.  Most risks associated with metadata payloads are
avoided when the following rules are respected:
1. the URI conveys only specific, limited knowledge or authority
2. the URI protects the information it carries by a level of
   obfuscation such as encryption and/or indirection via a random key
3. the URI is confined to secure data paths
4. the URI is restricted to a single use and/or is valid only during a limited
   lifetime

For example, a calendar system may provide an option to share a
calendar with another user.  The access right may be designated by a
unguessable URI that can be sent to the other user, who on applying it
obtains read access in a coordinating mail application to the first
user's mailbox.

Adequacy of data path security is difficult to assess and great care
should be exercised in using this pattern.  The calendar case works
because the URI in question has special use contexts (it is not likely
that is will be used for general browsing or bookmarking), it conveys
limited authority (read access to one calendar, not login access to an
email account), email and HTTP connections are assumed to be
sufficiently private, and the providing and consuming applications
both take steps to minimize disclosure risks.

</snip>

Best
Jonathan

[1] http://www.w3.org/2001/tag/group/track/actions/278
[2] http://www.w3.org/2001/tag/doc/metaDataInURI-31#hideforsecurity

Received on Sunday, 27 December 2009 16:47:16 UTC