Re: [ogpx] Protocol for permitting policy decisions

[David W Levine <[e-mail]>]

I want to point out an important related concept for much of this 
discussion. 

If one's goal is to *know* that someone actually is following a policy one 
has, especially a policy with real world implications, the process has to 
ground out in provable statements. 
In fact, for cases where the policy covers legal liabilities, it has to 
ground out in legally meaningful stuff. I studied distributed systems, not 
law, so don't take any of this as a legal pronouncement,
but.. If I'm going to trust a third party Agent Domain to tell me 
something that has legal consequences, I'm probably going to want that 
statement tied down with a digital signature or similar
proof, that links to a real world document. 

So.. My personal suspicion is that what we'll see comes much closer to 
this:

"In order to have rights beyond "guest" on this region, you, or your agent 
domain, on your behalf, needs to have signed the TOS document. I will 
demand a digitally signed proof of this, as metadata when you 
request acess to my region."

- David
~ Zha






Infinity Linden <[e-mail]> 
Sent by: [e-mail]
10/05/2009 03:39 PM

To
Magnus Zeisig <[e-mail]>
cc
"[e-mail]" <[e-mail]>
Subject
Re: [ogpx] Protocol for permitting policy decisions






right. this is similar to what i was talking about in one of the
previously mentioned options. i mentioned that the region might need
to call back into the agent domain to get more information about a
particular agent. to me it looks like you're suggesting a two-message
handshake instead of the region turning around and querying the agent
domain.

lemme draw some diagrams:

"name" and "age" are bits of data that, like you might expect, are an
account identifier and the account holder's age. "rez cap" is the
capability used to establish the agent's presence in that region. "age
> X? cap" is a capability granted to the agent domain that's supposed
to be used by the agent domain only if the agent domain agrees that
the account holder is older than X.

option 1: information push

AD ------------ ( name, age ) ---------> RD
AD <------------- (rez cap) ------------ RD

option 2: RD queries the AD

AD --------------- (name) -------------> RD
AD <----- (is name older than X?) ------ RD
AD -------------- (yes/no) ------------> RD
AD <------------ (rez cap) ------------- RD

option 3: multi-message handshake

AD --------------- (name) -------------> RD
AD <-------- (X, age > X? cap) --------- RD

AD ------------------------------------> RD (age > X? cap)
AD <------------ (rez cap) ------------- RD


option 3 here is my attempt to model what magnus is talking about, but
with a RESTful capability system.

-cheers
-meadhbh

On Mon, Oct 5, 2009 at 1:55 AM, Magnus Zeisig <[e-mail]> 
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> If I register with an agent domain, or authentication service, whichever
> should be the proper name for it, I will most probably hand them some 
pieces
> of information about myself that I don't want disseminated to anyone.
> Therefore, I think the protocol for granting access to regions and other
> services should not include such information explicitly, but rather let 
the
> agent domain/authentication service just answer questions from the other
> domain/service if the parameters are within acceptable range.
>
> Instead of the revealing (meta-handshake):
>
> Agent domain:
> request access for
> user: [e-mail]
> age: 18
> gender: male
> sexuality: bi
> country: pt
> languages: pt, es, en, de
> length: 1.82
> weight: 122
> color of socks: blue
>
> Region domain:
> access granted for
> user: [e-mail]
>
> The handshake should instead be:
>
> Agent domain:
> request access for
> user: [e-mail]
>
> Region domain:
> require parameter values
> languages: es AND (de OR hb OR ru)
> length: [1.21-2.42]
> color of socks: pink OR blue OR black
> hairdo: shaved OR ponytail
>
> Agent domain:
> required parameter values
> languages: yes
> length: yes
> color of socks: yes
> hairdo: n/a
>
> After which the region domain might decide that the missing hairdo 
parameter
> is not crucial and grant access, or refuse access because of it:
>
> Region domain:
> access denied for
> user: [e-mail]
>
> This has the benefit of permitting service providers to require what 
user
> parameters they think are important, be it age or color of socks, but 
the
> disadvantage of some extra overhead and the risk of balkanization 
because of
> requirements of "odd" parameters only supported by few services. The 
latter,
> however, I believe will become self-eliminating, because such services 
will
> probably not find many users. Either way, I don't think the protocol in
> itself should require any particular parameters, like age or color of 
socks,
> just provide the means to communicate any parameters, and perhaps 
suggest a
> list of possible, but not required, parameters and formats for values, 
like
> options, ranges and enumerations. The same kind of handshake could also 
be
> used when requesting access to asset services and the like, even if
> parameters like "object types" and "ip agreements" may be more important
> than "color of socks" there.
>
> Best regards,
>
> Magnus
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: 9.8.3 (Build 4028)
> Charset: utf-8
>
> wsBVAwUBSsm0cO5MlU9XyaiSAQgEgAgAiNiznZa4fJN+iIm4Lul4iUpPNytexn9g
> rJWLZ4oevewngvSCOwhslseXKN+OTCUpSPq0vGxRIl58n+u9P56q0X4pYBZ5wsqc
> YAPdd6zGtQpR+21XQ8oWM948LEdGxba8mNO1gDygqtIyx0suBYkvYUWyYitwlDpu
> ofvDew+JT140ApmX/d1dTyglxyYv6qnDf8iDsHsNiWYI1ImB5a/hvPK0TkCVFvzr
> vLXfL5BfCXK0I3tJbLpv/OoUFEn5/emzehu3uavuQfQqQM0uBpw8WVSQGXqZziKb
> 6i8YpDvBrIkNL4syGhmAs7ZLUqpZEfoWq2LbGasqhVMmDCBkakrPpg==
> =H2Fj
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>
_______________________________________________
ogpx mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ogpx