Re: [ogpx] Protocol for permitting policy decisions

[Infinity Linden <[e-mail]>]

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
>
>