WARP and DAP Policy

Looking at WARP [1] , I see it is currently only defined in a widget context. In conjunction with Widgets Packaging and Config [2] it does two things:

1. Indicates whether an API requires access control, via the <feature> element in P & C, where an IRI is defined for each API.

2. The WARP <access> element  indicates allowed network access for specified  origins, and possibly subdomains.

Policy for network access is by default to deny unless one or more access elements are specified, in which case allow is specified for the union of them.

There is no limitation of access to specific APIs or finer granularity. It is very simple - access to network resources based on scheme/authority and possibly subdomains.

It could be extended to consider explicit trust domains, as follows

(1) add optional trust attribute to access element. If present that trust domain must be validated for access to be allowed.

example
<access trust="URI" origin="URI" />

(2) Define  the trust element

<trust id="id">

 with the following children (ds11  prefix refers to elements  defined by XML Signature 1.1 [3], ds to XML Signature 1.0)

<SignatureReference URI="uri" /> - point to XML Signature to be validated to establish trust, e.g. widget author signature

<ds11:KeyInfo> - the key information that must be validated to establish trust. This can be inline with ds:X509Data element, or with new SDP element (as currently specified [4]), or may reference a KeyInfo by URI using ds11:KeyInfoReference. Validation means cert path validation, revocation check etc in X509 case.

(3) Address more complicated use cases by allowing <deny> or <allow> children of the <access> element.

If more than one, processed in order until match achieved. Yes, this is along the slope toward XACML rules and combinations.

Child of <deny> or <allow> is parameter value pair.

<parameter name="name">value</parameter>

(4) Add a feature attribute to access element to bind to that feature.

Example:

Thus the premium rate abuse example for Spain and UK might be as follows:

<-- allow unless denied within this access element -->
<access trust="#signed-source" feature="messaging.*.send">
        <deny>
        <parameter name="recipients">+4409*</parameter> 
        </deny>
        <deny>
        <parameter name="recipients">+34806*</parameter>  
        </deny>
</access>

<trust id="signed-source"
      <SignatureReference URI="#author-signature" />
      <ds11:KeyInfo>
         <ds11:KeyInfoReference URI="#author-signature-key-info" /
      </ds11:KeyInfo>
</trust>

---
to deny all numbers unless allowed (e.g. only allow UK):

<access trust="#signed-source" feature="messaging.*.send">
        <allow>
        <parameter name="recipients">+4409*</parameter> 
        </allow>
        <deny>
        <parameter name="recipients">*</parameter>  
        </deny>
</access>

If the logic within the access element becomes more complicated it can approach XACML rule combinations etc but an open decision is how much is needed.

regards, Frederick

Frederick Hirsch
Nokia

For tracker, this completes ACTION-201

[1] http://www.w3.org/TR/widgets-access/

[2] http://www.w3.org/TR/2009/CR-widgets-20091201/#the-feature-element

[3] http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.html#sec-KeyInfo

[4] http://dev.w3.org/2009/dap/policy/Profile.html#values-and-types

Received on Tuesday, 29 June 2010 21:33:29 UTC