Access
In a world in which objects and
information are networked together, privacy and security
are of paramount concern. Not all the information
produced by this new electronic infrastructure should
be generally available. On the contrary most - if
not all - the information should be limited to select
groups of individuals.
Even
further, not all information is generally useful or
appropriate. Detailed medical literature, for example,
is unrestricted, but not helpful to the average patient.
The
Physical Markup Language provides a mechanism to both
restrict and target information to select individuals
and groups. We use the term
access here to describe both the mandatory and
preferential restriction of data.
The
Physical Markup Language uses a form of role-based
security to provide authorization, access and filtering
of object information. A role
is a category of users with shared security privileges.
An administrator ,
manager or engineer
are all examples of a role.
Assignment
of role privileges allows consistence of access as
individuals move into and out of various functions.
Roles
may further be used to target and filter information
for maximal benefit. In fact, using some of the data
structure discussed in this document - such as the
timestamp - access rights can
change over time.
In
this Chapter, we define roles and access methods to
the data structures of the Physical Markup Language.
Access
In
this version of PML, we define an
access element, which contains access and security
information.
<access>
. . . </access>
Like
the timestamp, or ts
element, the access
element may be contained in
any other PML element or contain
any other PML element or group of elements.
In
this way, we can freely tag data as limited access
or preferential presentation. If the access element
is included, information will be filtered according
to its contents.
Role
The
access element includes a role
element, which defines the both the role of the
individual or group. The role
element contains a string signifying the particular
role - such as "Bank Teller"
, "Customer" ,
"Agent" , "Administrator"
or "All".
<role>
String
</role>
Logic
The
access element may have one
or more additional access
elements, in this way more complex access conditions
can be provided. Using a type
attribute, which may be set to
"and" , "or"
or "not" , the specification
may produce arbitrary Boolean combinations of access
rights or restrictions.
<access
type=[and, or, not]>
<access type=[not]>
<role> String
</role>
</access>
<access type=[not]>
<role> String
</role>
</access>
. . .
<access type=[and, or, not]>
<access type=[not]>
<role> String
</role>
</access>
<access type=[not]>
<role> String
</role>
</access>
. . .
</access>
</access>
Since
we allow access
elements throughout a PML file, we have to interpret
the meaning of an access
element insider another. In other words, an access
element may contain a section of PML data, in which
other access
elements exist. In this case, we assume a access
element insider another access
elements overrides the former.
Data
types
For
convenience, we allow a special construction, in
which the access
element may contain a list of strings separated
by commas, indicating the element types
that are accessible by the particular users. In
other words, rather than embedding access
elements through the document, the element types
can simply be specified by in one place.
