[Requests] Comment on Geospatial eXtensible Access Control Markup Language (GeoXACML)

[Christian Elfers]

Dear OGC,

please find attached our comments on 
"Geospatial eXtensible Access Control Markup Language (GeoXACML)".
We help solving the issues mentioned if wished.

Best regards,
Christian Elfers


PART A


1. Evaluator:
   Christian Elfers
   con terra GmbH
   christian.elfers at conterra.de
   Martin-Luther-King-Weg 24
   Münster, 48155
   Germany

2. Submission: OGC 07-026, 
   Geospatial eXtensible Access Control Markup Language (GeoXACML)


PART B


0.1. Requirement: 
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.


1.1. Requirement: 
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 
GeoXACML. 
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 
example). 
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 
detailed enough. 


2.1. Requirement: 
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).


3.1. Requirement: 
'Encoding of resources should be optional/informative'
or
'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. 
1st comment: 
see #2, as beeing an extension there is no need to profile that 
special part of XACML whilest leaving other un-defined. 
2nd comment:
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 
interoperable. 

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:
urn:ogc:def:geoxacml:1.0:resource:Service-Id
http://www.w3.org/2001/XMLSchema#anyURI
http://www/wms_base?

Content type with URN:
urn:ogc:def:geoxacml:1.0:resource:Service-Type
http://www.w3.org/2001/XMLSchema#string
OGC:WMS:1.1.1

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.


4.1. Requirement: 
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
or informative.


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
referenced geometry.


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"
______________________________________________________________________

Christian Elfers               
Head of int. spatial data infrastructure solutions

con terra - Gesellschaft für Angewandte Informationstechnologie mbH

Martin-Luther-King-Weg 24
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
skype: chrisx9
______________________________________________________________________