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

[Al Gilman]

It is possible that capability advocates will find a more receptive
audience in
the Global Grid Forum Security Working Group.

<http://www.gridforum.org/>http://www.gridforum.org

As I have indicated earlier, here is a community that knows it has a
problem of
restricted delegation, which I have at least once suggested to them should be
viewed as a matter of communicable categorized authorization.  Smells
something
like a capability?

The excuse for the fact that the Grid Forum isn't just an anonymous cluster of
IETF Working Groups is to achieve focus on some domains of metacomputing and
create a climate that is a notch more open to risk taking and innovation,
while
still targeting universal standardization as the end state of practice.  One
view is that it can serve as a lab in which to prepare technologies for IETF
consideration.  So consider it as an alternative to either MIME or CalSch as
your stepping stone and you may discover a path to daylight.

No guarantees.  I am a lurker there as here.  But from afar, it looks like a
possible fit.

Al

At 10:49 AM 2001-07-11 , John Stracke wrote:
>"David L. Nicol" wrote, on a separate list but CC:ed to me:
>
>> 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.
>
>And for good reason: the IETF generally avoids trying to do things that don't
>have wide experience yet; it makes for working groups that trail off into
death
>spirals.
>
>Implementers of the various iCalendar protocols can experiment with
capabilities
>on their own; if they turn out to be useful, then they can be standardized.
>
>> 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
>
>--
>/================================================================\
>|John Stracke    | <http://www.ecal.com/>http://www.ecal.com |My opinions are
my own.  |
>|Chief Scientist |===============================================|
>|eCal Corp.      |We want forty million helicopters and a dollar!|
>|francis@ecal.com|--"Dinosaurs"                                  |
>\================================================================/
>
>
>
>_______________________________________________
>cap-talk mailing list
>cap-talk@mail.eros-os.org
><http://www.eros-os.org/mailman/listinfo/cap-talk>http://www.eros-os.org/m
ailman/listinfo/cap-talk
>