[ogpx] Policy between services

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

I've changed the subject, because the thread drift has become brutal 

I want to make a couple of points, one of, something akin to etiquette. 
Lets start there. 

I don't think it advances our technical agenda when we start dragging in 
philosophical,
political and cultural issues around some of the use cases people are 
advancing. 
One persons abhorred policy is another's legally required to stay in 
business use case. 

We also need to be careful to separate the use cases, such as "I don't 
want people
who haven't passed some form of age verification accessing some virtual 
spaces"
from possible mechanisms for achieving those use cases. 

It is also worth keeping in mind the limitations of  what we can express 
in a protocol
and what  mechanisms we have for allowing services to express and manage 
policy.

At the end of the day the policy enforcement points are primarily when 
either:

        1) first contact is made with a cluster of services, where 
meta-data is
            included in the request, and based on this, and policy, caps 
are
                    granted (or not) and meta-data is associated with 
those caps. This
            is one of the nice bits of a cap grant, it permits a policy 
decision to
                    be made once, and encapsulated in the cap(s) granted. 

        2) at invocation of a cap, mediated by meta-data associated with
                    the request. This is notably more expensive, as it 
requires the check
                   to be made in all cases, but it provides a finer 
grained policy enforcement
                   scheme. 

 
Also note protocol is unlikely to directly encode complex, "semantic" 
concepts such as 
"age-verified." They are far more likely to permit set of deploys to 
define mechanisms 
for making (and possibly in some cases verifying)  properties of the users 
they represent 

This is rather like the point made by several people, a distinction 
between having the
spots to carry the information, and mandating the contents of those slots. 
The nice
thing about LLSD protocol elements  is that they are easily extensible. if 
we say "Here is where
a set of properties that the authenticating service vouches for about the 
user go" 
we can stop there, and allow the community to define the properties they 
care about. 

We also need to recognize the limits of any specification. We describe 
mechanisms
to enable interoperability. We cannot mandate how people extend those 
mechanisms
nor deployment choices they make, nor policy choices they make which are 
beyond those
defined in the specifications. 

Lastly, for better or worse, some of the use cases involved in policy 
effectively are
about linking a real world legal contract with the use of services. We're 
not going to
flow protocol elements which are legal contracts, but.. we may well end up 
using
things like PKI to prove the a given end user or service is in procession 
of a proof
token for having signed a specific legal document . In this case, less a 
matter
of defining the mechanisms as much as leveraging existing ones. 

- David Levine
~ Zha Ewry