[Requests] Comment on Geospatial eXtensible Access Control Markup Language (GeoXACML)
christian.elfers at conterra.de
Wed Jun 13 05:09:53 EDT 2007
please find attached our comments on
"Geospatial eXtensible Access Control Markup Language (GeoXACML)".
We help solving the issues mentioned if wished.
con terra GmbH
christian.elfers at conterra.de
2. Submission: OGC 07-026,
Geospatial eXtensible Access Control Markup Language (GeoXACML)
Clearify general purpose of GeoXACML
0.2. Implementation Specification Section number: Introduction, 6
0.3. Criticality: Normal
0.4. Comments/justifications for changes:
XACML is a language with defines a rights encoding model and
authorization descision context encoding, GeoXACML is an extension
to add spatial data types and authorization decision functions to
the rights encoding model only.
GeoXACML does not define the access control system itself, nor does
it allow enforcement. It includes no extension for the authorization
descision context encoding (request/response). This should be stated
clearly. However, XACML includes a possible model for a whole access
control system (including PEP, PDP, PAP, PIP) which is a good model
from our point of view, but for GeoXACML it is only informative.
Clearify difference of policy language/rights expression language
and the influence of GeoXACML beeing a policy language.
1.2. Implementation Specification Section number: General
1.3. Criticality: Major
1.4. Comments/justifications for changes:
It is written in the preface that GeoXACML is meant to be
a policy language, not a rights expression language without
definiting both terms and how they differ in relation to
The difference seems to be that GeoXACML is suppose to
describe access control on service requests/response and
is not persistently stored with the geospatial data files
(such as classical mp3 drm). This should be named as
difference not a general PL/REL difference. This would be
confusing, amibigous not by a "normal" reader.
REL´s may be stored with data files, but that is not all.
REL´s are meant to be created/applied on the fly as well (e.g.
for the license click-through use cases). As click-through
is very much applicable to service access control, GeoXACML
rights may be used as "REL" in that sense too.
But: the specification is an extension to XACML, interoperable
usage of GeoXACML rights between different node will require
more than this extension (like a profiling, describing non-
ambiguously the format of subjects/actions/ressources for
Please make this very clear in scope or introduction: GeoXACML
is an extension, it does not ensure interoperable usage and
transport. For the latter, GeoXACML specification is not
Clearify the scope of naming "ResourceAttributeDesignator"
2.2. Implementation Specification Section number: 7.3, Annex A
2.3. Criticality: Major
2.4. Comments/justifications for changes:
In "7.3, OpenGIS Web Services specific ResourceAttributeDesignator"
the denomination of resources is optional. "Annex A (normative)"
implies that the usage is mandatory. With respect to issue #1,
GeoXACML is an extension and GeoXACML documents are not meant to
be transported. Therefore the denomination of resources is
an implemenation specific issue. However, IF interoperable usage
is desired, not only the denomation of resources but the
denomination of action and subjects (and environment attrbutes)
need to be defined non-ambiguously (see issue #3 as well).
'Encoding of resources should be optional/informative'
'Provide fully qualified denominators for subjects/actions/resources'
3.2. Implementation Specification Section number: Scope, 7
3.3. Criticality: Major
3.4. Comments/justifications for changes:
The scope list only attribute designators for resources to be
potential subject for standardization.
see #2, as beeing an extension there is no need to profile that
special part of XACML whilest leaving other un-defined.
If denomination is part of GeoXACML, it should done for resources,
action, subjects and environment attributes. Otherwise it is
possible to encode totally different policysets, all claiming to
be GeoXACML compliant but most likely they will not be
To achive interoperablitiy, non-ambigious attribute designators
are needed (at least):
This would include a URN-styled denominator, the technical
data type, the content type and instance identifier. Example
for a wms resource definition using 2 designators (technical
data type not shown):
Instance identifer with URN:
Content type with URN:
Such as schema is applicable to all kind of resources (including
sub-resources like layer or feature types that are assigned to
a service resource). As well as to actions, subjects and environment
attributes. If interoperablitiy is desired, such a schema may need
to be defined per OGC resource/service.
Encoding of actions as resource to be optional/informative
4.2. Implementation Specification Section number: 7.3
4.3. Criticality: Major
4.4. Comments/justifications for changes: [Comments]
To encode a service operation as resource is only one of
various possible interpretations. As laid down in #2 and
#3 it is not necessary for an extension to define a partly
profiling of XACML. Therefore it should be delared optional
5.1. Requirement: GML-Objects by-reference within GeoXACML
5.2. Implementation Specification Section number: 7
5.3. Criticality: Normal
5.4. Comments/justifications for changes:
GeoXACML Documents include geometries for spatial authorization
by-value. That way, the gml objects are included in the policies.
The examples provided only deal with very simple geometries. We
doubt that those simple geometries will match the requiremenets
for "real world" use cases. Those will most properly deal with
any sort of administrative units as "spatially authorized areas".
As this units can be of any complexity/size and a proper spatial
authorization will need a certain degree of detail, we expect that
gml objects stored by-value will lead to massive performance
problems. To avoid this, we propose to add the possibility to
include gml object by-reference. Such a reference could be a
pointer to any WFS and a filter expression describing the
6.1. Requirement: Remove typos
6.2. Implementation Specification Section number: various
6.3. Criticality: Editorial
6.4. Comments/justifications for changes:
- Annex (A2): It should be "Operation-Id" instead of "Service-Id"
- General "resource" instead of "ressource"
Head of int. spatial data infrastructure solutions
con terra - Gesellschaft für Angewandte Informationstechnologie mbH
48155 Münster, Germany
phone: +49 (0)251 7474-333 fax: +49 (0)251 7474-100
mail: christian.elfers at conterra.de web: http://www.conterra.de
More information about the Requests