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

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
>    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
> ______________________________________________________________
> ________ 