[Cap-Talk] Re: Is there a capability RFC?

David L. Nicol david@kasey.umkc.edu
Tue, 10 Jul 2001 17:05:55 -0500


John Stracke wrote:
> 
> "David L. Nicol" wrote:
> 
> > it occurs to me
> > that a Standard Capability Protocol (capabilities are 1024 bits long,
> > they include time-stamps and encooded origin info in a standard way,
> 
> Can you define "capability" better, please? I don't follow what you want it
> for.

"capability" is a robust method for delegating (and rescinding, and
tracking)
authority or all kinds.


Not Authenticity, but Authority.


X session cookies are a good example.  Another is the random codes that
prevent
fake mailing list subscriptions.  CGI session cookies too -- they are
random
strings of characters that give one the capability to use a particular
shopping
cart object.

If iCal (or MIME, for that matter) had a standard CAPABILIT[Y|IES]: header
built
into it, I, as an operator of a calendar, could ask my calendar for some
posting
capabilities which would expire at the end of the year, and distribute
these
capabilities (they would look like PGP signatures -- you know, binary
garbage)
to the people who are authorized to list events on the calendar, and they
would
use capability-aware tools to submit the items to the calendar, which would
include the capability, associated with the event they are sending in, and
the
calendar would check the capability, and if it is good, go ahead and list
the event, and if it is not, the calendar would pass it on for moderating.

I believe this is desired functionality which is not currently addressed by
the standard, in fact it is explicitly delegated to the implementors.

Capabilities could become a framework for authorization interoperability.

I am not suggesting that any of the flexiblity in designing arbitrarily
complex authorization systems be taken from the implementors; I am merely
suggesting that specifying a place for such information to go, if it is
used in an implementation, would ease interoperability.

Since a general purpose authority delegation scheme is larger than
calendaring
(standardizing VERPs comes to mind as another possibility -- a VAriable
Envelope
Return Path could be considered as a Capability that allows a MTA,
"exercising
it" by bouncing a mail to the address, to unambiguously report a problem
with
a particular address) I think an RFC on incorporating them into MIME, which
would then get inherited by all projects that rely on MIME, would be a
better
solution than including them in the iCalendar project.

Including them in the iCalendar project, and expecting them to get
back-ported
into MIME, makes sense too.


-- 
                                           David Nicol 816.235.1187
                   "Perl was born in downtown Hell!" -- Matt Youell