[Requests] Comment on Geospatial eXtensible Access Control Markup Language (GeoXACML)
christian.elfers at conterra.de
Wed Jun 13 08:52:16 EDT 2007
(sorry for double posting, the mail was bounced back
when i sent it first time). christian.
> 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
> 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'
> '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:
> 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
> 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
More information about the Requests