Re: [ogpx] Seed capability behavior

so... if the question is, "should the seed cap be a one shot or
persist?" then allow me to offer the following observations:

1. why having the seed cap being persistent is "good"

1.1. if the seed cap persists for a fixed period of time, the client
may request additional services from the seed cap later. it's possible
we may want to wait to issue service caps until the client actually
tries to do certain things (like spend money, transfer items,
inventory access, etc.)

1.2. if the seed cap persists for a fixed period of time, it allows
service caps to have shorter lifetimes. deployers may want some caps
(like caps for spending money and transferring items) to have a
shorter lifetime than others (like caps for connecting to public
regions or caps for getting the grid status.)

by persisting the seed cap, the client may request a new service cap
from the seed without having to re-authenticate.

2. why having the seed cap being persistent is "bad"

2.1. allowing the seed cap to persist introduces a "Time of Check,
Time of Use" vulnerability to the system. ( see
http://en.wikipedia.org/wiki/Time-of-check-to-time-of-use ). for
example, imagine that the agent domain's authority cancel's an account
after a seed cap is granted, but before it expires. the client will
still be able to request services with it.

--
   infinity linden (aka meadhbh hamrick)  *  it's pronounced "maeve"
         http://wiki.secondlife.com/wiki/User:Infinity_Linden

On Wed, Jan 20, 2010 at 14:37, David W Levine <dwl@us.ibm.com> wrote:
>
> ogpx-bounces@ietf.org wrote on 01/20/2010 05:16:54 PM:
>
>> [image removed]
>>
>> [ogpx] Seed capability behavior
>>
>> Hurliman, John
>>
>> to:
>>
>> ogpx@ietf.org
>>
>> 01/20/2010 05:17 PM
>>
>> Sent by:
>>
>> ogpx-bounces@ietf.org
>>
>> The current handling of seed capabilities in Second Life is that
>> they are treated like one time capabilities. The viewer knows a list
>> of all of the capabilities it wants ahead of time, and makes a
>> single request containing the full requested capabilities list. Are
>> we mandating that VWRAP seedcaps must be one time capabilities or
>> must not be one time capabilities? If it’s up to each
>> implementation, we’ll get a situation where some clients make
>> multiple requests to a seed cap and are incompatible with services
>> that chose to implement one-time seedcaps.
>>
>> John_______________________________________________
>> ogpx mailing list
>> ogpx@ietf.org
>> https://www.ietf.org/mailman/listinfo/ogpx
>
> My (fairly strong) preference is that they be persistent caps. I see no
> reason to force a client into the model of
> asking for (and keeping track of) everything when it doesn't need it. Making
> it possible to pull caps as you need
> them is upwards compatible with getting them all at once, and allows a more
> flexible usage.
>
> I'd also point out that, if a service provides a "short term" cap which
> expires, we need a way to permit the client
> to renew the cap, so that also strongly argues for a persistent cap, and, a
> fine grained one as well. I would
> not want to force a re-get of every cap, when any single cap expired.
>
> - David
> ~ Zha
>
>
>
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
>
>