OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

humanmarkup-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: Open Identity


While I don't disagree with this, I am hoping these kinds 
of applications are someone else's job.  I see enough 
of this kind of stuff already. :-(  Still let's pursue 
the trail where it leads.

My instincts are that the first line of users of 
HumanML are sociologists, anthropologists, semioticians, 
etc.  After that, the entertainment industry can mine it 
(see genre applications, VRML, etc).  The 
fact that their work can then inform the work of 
the public safety systems is a valid use, but the 
ps systems already gather and correlate much the information 
they need.  In fact, we are borrowing from their 
schemas now in the physical characteristics section (NIBRS). 

While I don't think it appropriate to provide full details of 
public safety schemas, there is a quite a bit of information 
there to be used for identification and profiling, but the 
next levels include special watch lists  created by 
the national security agencies but not made publicly 
available and only available to public safety by special 
request of the security agencies themselves as BOLOs. 

The operation/process does differentiate because it points up 
the aspects of policy controls over use and access. 
In the law enforcement domain, there are three 
subdomains that interlock to govern the inputs, outputs 
and subproceses of each:  

o police, fire and emergency services (public safety)
o courts (not public safety but an inner peer data partner)
o corrections (prisons) (public safety and inner peer to police)

The police in particular are governed by the courts.  
Use of and access to certain information or execution 
of certain processes require judicial permission and 
these are determined by policy or fiat (judge signs 
warrant).  Here is an example.  An officer 
in a police car making a vehicle stop wants to know if the person 
driving the car owns the car (identification 
and association) and do they have outstanding 
warrants (BOLO) and this information can enable 
immediate authorized action.  Next they want to know 
if the driver paid their utility bill last 
month (profile based on personal disorder). 
They can get the first set of information 
from NCIC and DMV.  The second requires a 
court order but it is for secondary action 
(follow up, hold, etc).  In the case of a 
BOLO, suspicion is enough to hold and that 
is actually how one of the foreign nationals 
involved in the bombings was captured: a routine 
traffic stop.

They cannot use their resources to collect 
the depth and kind of information we may be enabling 
except in very special cases (eg, application of 
haptics to juvenile analysis).   The information 
might be useful for decision support and policy 
making at higher than the street level (eg, 
policy formulation by the federal government 
trying to determine what special needs are for 
some given class of immigrants).   The issue 
here is task appropriateness.  However, yes, 
one could conceivably use HumanML data for 
an interpreter that is scanning for possible 
terrorists.  I suspect that information would 
be very limited in application compared to the 
BOLOs created by the intelligence groups but 
used in concert with them, would set off 
alerts in the name databases such that the 
officer stopping the car could conceivably 
get the court order much faster.

len 

-----Original Message-----
From: Kurt Cagle [mailto:kurt@kurtcagle.net]

It's a very valid distinction, and one that makes things interesting from
the intersection standpoints of other groups. For instance, last I heard
there was an OASIS-TC that were attempting to create a consistant ACL
mechanism for OASIS processes (targeting mainly ebXML). I think this
actuallly raises the issue about the degree to which HumanML should
subscribe to the notion that authentication falls under its charter.
Identity is not a process -- it's a state that can be quantified in terms of
some specific charter (the discussion we had earlier about the need to
include the author as part of authorization). Identification, however, is a
process, and is in fact a process on multiple levels:

1) Identification via ownership of a key. This level of identification is
largely synomous with authentication -- if you have the key (or a necessary
and sufficient part of the key) then you are assumed to be the person who
you claim to be.

2) Identification via characteristics. This level of identification creates
a best fit criterion that establishes a level of confidence that the person
is who they claim. This would essentially cover the whole domain of
biometrics.

3) Identification via profiling/association. This does not attempt to
establish a specific individual uniquely, but instead attempts to determine
whether they conform to a set of individuals likely to perform some action
(profiling of terrorists, for instance or profiling of potential customers
for marketing purposes).

Each of these have their own notion of identity. What we're doing with
HumanML seems to be somewhere between (2) and (3), which could conceivably
even be joined together - what differentiates them is not the operation but
the result; either "Is this the person in the Wanted Dead or Alive picture?"
or "Does this person look have characteristics that match a likely
Terrorist?").


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC