Last week we posted an idea for automatic processing of legal agreements. Today, we want to show a case study, which is still far from complete and definately not final. What this demonstration captures is how we want other parties to communicate with us. Something like this could be used by companies to automatically decide whether they can sign you up for email marketing, and so on. Moreover, it provides handles for law enforcement.
See also: Automating Legal Terms
The text below is interspersed with formal bits and pieces, together tying up an ASN.1 specification. The data formats that it generates can be encoded in binary forms, XML and so on, and a plethora of tools exists to speed up its automatic processing.
CommunicationFilter DEFINITIONS ::= BEGIN
There are plenty of
well-defined attributes
such as emailAddress,
streetAddress and telephoneNumber. We simply use that to our advantage.
IMPORT Filter FROM rfc4515;
The form of a Communication Filter
The big thing about a communication filter is to specify a number of rules of conduct for potential communication peers. These rules are a sequence of individual rules, gradually developing from general statements to exceptions; later rules can override preceding ones. An empty sequence signifies the default privileges defined by applicable law, and the first rule may be seen as a first exception to that default situation.
CommunicationFilter ::= SEQUENCE OF RuleOfConduct
A rule of conduct is either a permission or a retraction of a pattern of communication. These patterns involve communicative actions taken towards our own communication end points and are applied to a selection of potential peers. All of the actions, end points and potential peers are described as sets, and the rule of conduct, whether permissive or a retraction, applies to all combinations. Note that either of these sets could be empty, but that would mean that this rule has no impact on anything. Contrast that to the possibility of removing these entries; when that is done, it is considered to range over all possible instances.
RuleOfConduct ::= SEQUENCE {
isPermitted [0] BBOOL,
action [1] SET OF Action OPTIONAL,
endpoints [2] SET OF CommunicationAddress OPTIONAL,
appliesTo [3] SET OF PotentialPeer OPTIONAL
}
An action description is an object identifier that we hope will be
recognised. Might communication filters like these ever be embedded in law,
then it would be important to make clear which set of actions must be
recognised, and whose responsibility it is to see that these are found.
These are the object identifiers
that we described as being useful for their universality; and for which
we stated that a small, and widely carried set would be useful.
We define a number of examples below, under oid-action.
Action ::= OBJECT IDENTIFIER -- For instance, oid-action-...
Similar in nature to actions, there are categories of potential peers, and
these too are described as object identifiers, described under oid-peer
below.
PotentialPeer ::= OBJECT IDENTIFIER -- For instance, oid-peer-...
Communication addresses can range over many values. As was stated for actions, any embedding of these communciation filters in law would have to be clear on the required support for a selection from the wide range of possibilities covered here. In general, it a communication address is a set consisting of entries that can take various forms:
- The context may provide it, e.g. an email sender, a directory object or a digital visiting card;
- It may be specified in the form of a Filter applied to directory attributes;
- A directory reference for a communication endpoint.
These choices are all spelled out below.
CommunicationAddress ::= CHOICE {
contextual [0] NULL,
filter [1] Filter,
ldapref [2] LDAPDN,
...
}
Now that it is clear how a communication filter can be structured, it is time to turn to the actions and players.
Object Identities for Communication Actions
Let's start an (experimental) object identity tree under which we shall
define our communication actions by adding as many "dot number" extensions
as we like, starting with 1.3.6.1.4.1.44469.666.25.1.1; note that it is
possible to make statements at this general level, and claim the opposite
in later rules of conduct.
oid-action ::= { 1 3 6 1 4 1 44469 666 25 1 1 }
Various forms of communication action can now be defined underneath the
object identity "tree" of oid-action, by adding numbers; for brevity's
sake we let the labels speak for themselves:
oid-action-initiate-contact ::= { oid-action 1 }
oid-action-response ::= { oid-action 2 }
oid-action-followup ::= { oid-action-response 1 }
oid-action-reminder ::= { oid-action-response 2 }
oid-action-repeated ::= { oid-action 3 }
oid-action-newoffer ::= { oid-action 4 }
oid-action-newsupdate ::= { oid-action 5 }
oid-action-response-human ::= { oid-action-response 1 }
oid-action-response-automated ::= { oid-action-response 2 }
oid-action-followup-human ::= { oid-action-followup 1 }
oid-action-followup-automated ::= { oid-action-followup 2 }
oid-action-reminder-human ::= { oid-action-reminder 1 }
oid-action-reminder-automated ::= { oid-action-reminder 2 }
oid-action-repeated-human ::= { oid-action-repeated 1 }
oid-action-repeated-automated ::= { oid-action-repeated 2 }
oid-action-newoffer-human ::= { oid-action-newoffer 1 }
oid-action-newoffer-automated ::= { oid-action-newoffer 2 }
oid-action-newsupdate-human ::= { oid-action-newsupdate 1 }
oid-action-newsupdate-automated ::= { oid-action-newsupdate 2 }
Many more things could be defined, but you probably get the idea; you could
deny general contact patterns with 1.3.6.1.4.1.44469.666.25.1.1, then
permit any responses to your emails with 1.3.6.1.4.1.44469.666.25.1.1.2
and only human-sent followups with 1.3.6.1.4.1.44469.666.25.1.1.1.1
and this format can be processed automatically by software. You can also
see how others might elaborate on the actions by adding their own under
another "prefix" than oid-action, and how it would be needed to somehow
regulate what sources of these object identifiers must be processed.
Object Identities for Communication Peers
We now setup a second "tree" of communcation peers that we recognise.
We start off defining the general "prefix" for such object identifiers,
1.3.6.1.4.1.44469.666.25.1.2
oid-peer ::= { 1 3 6 1 4 1 44469 666 25 1 2 }
And again, in the interest of brevity we let the labels speak for themselves:
oid-peer-friend ::= { oid-peer 1 }
oid-peer-commercial ::= { oid-peer 2 }
oid-peer-collegue ::= { oid-peer 3 }
oid-peer-collaborative ::= { oid-peer 4 }
oid-peer-interest ::= { oid-peer 5 }
oid-peer-commercial-present ::= { oid-peer-commercial 1 }
oid-peer-commercial-past ::= { oid-peer-commercial 2 }
oid-peer-commercial-future ::= { oid-peer-commercial 3 }
oid-peer-commercial-potential ::= { oid-peer-commercial 4 }
oid-peer-commercial-unrelated ::= { oid-peer-commercial 5 }
oid-peer-commercial-potential-requested ::= { oid-peer-commercial-potential 1 }
oid-peer-commercial-potential-offering ::= { oid-peer-commercial-potential 2 }
oid-peer-interest-optout ::= { oid-peer-interest 1 }
oid-peer-interest-optin ::= { oid-peer-interest 2 }
oid-peer-interest-optin-groupcomm ::= { oid-peer-interest-optin 1 }
As before, it should be obvious that this enables us to be expressive, with just
the right level of generality or specificity. We could grant all contact
with friends with 1.3.6.1.4.1.44469.666.25.1.2.1
or actively suppress commercial contacts with 1.3.6.1.4.1.44469.666.25.1.2.2
with the exception of present contacts 1.3.6.1.4.1.44469.666.25.1.2.2.1
and potential relations that we requested 1.3.6.1.4.1.44469.666.25.1.2.2.4.1.
This concludes this demonstration of how automated processing of legal terms could be described in terms that support automatic processing. We might define a directory attribute for it, and place it with our contact information in a directory. Or we might define a standard for attaching these statements to an email.
END
Much more can be said about this, for sure. For example, we did not cover restrictions, such as the use of encryption and/or digital signatures, and how our identities should be validated; these are all technical provisions that help to protect our privacy and security; it might for instance be used to ward off anything that looks like it came from your bank but that, given ignorance of these rules can be automatically classified as spam.
Because there are so many more possibilities, we are not proposing that you start using these example definitions. Instead, you should take the demo to heart as a statement that automation of legal terms is possible if we put our mind to it.
Are you interested in working out this example, or others? Then let us know how we could facilitate you -- we might setup a website, mail list and so on.
Go Top