Re: [ogpx] Protocol for permitting policy decisions

[Meadhbh Hamrick <[e-mail]>]

hmm.. okay. i like where we're headed here. carlo, what you're
recommending is similar enough to the use of a seed capability we
could almost call it the same design pattern. i like the idea of the
AD tell the RD something like, "hey... here's a list of keywords
describing concepts i'm concerned about." then having the RD respond,
"oh! you're concerned about <FOO>, well lemme tell you about <FOO>."
and then having the AD decide whether or not the RD's values for FOO
violate it's policy.

however. i'm not entirely certain we (linden) would use it all the
time, and here's why. the model we've been proposing is that AD's
would negotiate deals with RD providers and specify requirements and
policies in excruciating detail in legal documents. we would then use
the name (domain name or subject name from the client cert) to lookup
what we think the policy would be, and then act on it.

but...

i still like this scheme because a) it's really similar to the way
seed caps work, b) it adds flexibility to our system(s), and c) it
does what i was hoping... gives the AD the ability to make policy
decisions (like am i going to let this 15 year old user access
material that may land me in hot water with the local authorities.)

so... what we could do is make the request optional, but the response
manditory. this would mean we could still use the deployment model
listed above, but the "tourist" model can use the request. (i'm using
the term "tourist model" to mean where someone's AD attempts to place
an avatar in a region the AD does not have a previous trust
relationship with.)

On Wed, Oct 7, 2009 at 1:35 PM, Carlo Wood <[e-mail]> wrote:
> On Mon, Oct 05, 2009 at 12:39:32PM -0700, Infinity Linden wrote:
>> option 3: multi-message handshake
>>
>> AD --------------- (name) -------------> RD
>> AD <-------- (X, age > X? cap) --------- RD
>>
>> AD ------------------------------------> RD (age > X? cap)
>> AD <------------ (rez cap) ------------- RD
>
> Note, again, the need for a flexible protocol negotiation:
> we can't know, already, what all will be needed.
>
> Nevertheless, the more flexibility the better imho.
> I'd prefer to see this:
>
> AD ------(name, <list with keywords>) -----------> RD
> AD <-----(name, <list with keywords + ranges>) --- RD
> AD ------(name, yes/no)--------------------------> RD
> AD <-----(rez cap) ------------------------------- RD
>
> Where VWRAP will not define what keywords are possible.
>
> However, implementers might, for example, choose to use 'AGE' as keyword
> with an integer range, leading to a msg exchange like
>
> AD ------(name, (AGE)) -----------> RD
> AD <-----(name, (AGE, 21)) -------- RD
> AD ------(name, yes)--------------> RD
> AD <-----(rez cap) ---------------- RD
>
> or some might implement
>
> AD ------(name, (AGE, LIKES_BUNNIES)) -----------> RD
> AD <-----(name, (AGE, 13), YES) ------------------ RD
> AD ------(name, yes, yes)------------------------> RD
> AD <-----(rez cap) ------------------------------- RD
>
> For privacy reasons, I think it would suffice to
> just send the AND of all 'yes's, thus:
>
> AD ------(name, (AGE, LIKES_BUNNIES)) -----------> RD
> AD <-----(name, (AGE, 13), YES) ------------------ RD
> AD ------(name, yes)-----------------------------> RD
> AD <-----(rez cap) ------------------------------- RD
>
> or,
>
> AD ------(name, (AGE, LIKES_BUNNIES)) -----------> RD
> AD <-----(name, (AGE, 13), DONTCARE) ------------- RD
> AD ------(name, yes)-----------------------------> RD
> AD <-----(rez cap) ------------------------------- RD
>
> Again, neither 'AGE' nor 'LIKES_BUNNIES', would be defined by us,
> but we would define how to handle integer ranges, booleans,
> don't cares, string literals, and perhaps regular expressions.
>
> --
> Carlo Wood <[e-mail]>
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>