Re: [Powerbox] New draft based on further collaboration and prototyping

Hi David,

I think the Powerbox spec as is enables the PM1 and PM2 policy
management use-cases, and could support PM3 in some implementations.
In particular, the Powerbox spec defines a user interaction that
supports user-controlled configuration as described in PM1. The PM2
use case can be implemented by particular Provider implementations.
The Introduction.customer field identifies the Customer that is
requesting access to a resource. A Provider could use this field to
blacklist some applications, as described in PM2. The PM3 use-case
seems to require a means of prohibiting the user from using Providers
other than those that adhere to the external policy authority. A
particular user-agent might be implemented such that its Powerbox
comes pre-configured with a set of Providers and the user is
prohibited from extending this set. In this case, the user-agent would
want to ignore the Provider offers described in section 5, "Provider
Registration". If you like, I could add a sentence to this section,
noting that this is a valid user-agent configuration.

I believe the PM1 and PM2 policy management use-cases can be used to
address the abuse-cases listed later in the document by preventing the
malicious application from gaining access to private resources. It's
worth noting that the Powerbox interaction inherently offers some
additional protection in abuse case AC4 Phishing. Just as phishers
don't find it profitable to impersonate a computer's file selection
dialog box, impersonating the Powerbox is similarly unattractive. Even
if a phisher convinces the user that a window controlled by the
phisher is a file selection dialog, there's little to be gained, since
the phony window cannot give the phisher access to the user's files.
Only a legitimate file selection window can grant access to a user's
files. Similarly, impersonating the Powerbox's Provider selection menu
does not forward a requisition to any of the user's Providers, since
only a legitimate Provider selection menu can do that. A phisher might
have better luck impersonating a particular Customer and enticing the
user to grant access to a resource through a legitimate Powerbox
interaction. As described in PM2, the selected Provider can use the
Introduction.customer field to help protect against this phishing
vector. Consequently, I believe the impersonation techniques used in
phishing will be less useful for attacking a Powerbox interaction.
Malware that takes over the user's device will still be a problem.

The Powerbox does not attempt definition of a Portable Policy
language. An add-on specification could certainly do so and encourage
Providers to support importing of policies described in that language.
I don't think there's anything needed in the Powerbox specification to
enable such an effort. For example, the UI referenced from the
Provider.home link could support importing a portable policy.
Alternatively, an add-on specification could define a new attribute on
the Provider interface to link to a location for automated pushing of
a portable policy to a Provider. The user-agent could then
automatically push a portable policy to all registered Providers
whenever that policy was updated. Adding attributes to the Provider
Document is an expected extension mechanism for the Powerbox and
add-on specifications, such as one for Portable Policy, are welcome to
define such extensions.

I believe the current draft of the Powerbox spec meets many of the
needs described in the policy-reqs document and enables extension
specifications that could address remaining needs.

Best Regards,
--Tyler

On Tue, Jun 1, 2010 at 8:55 AM, David Rogers <david.rogers@omtp.org> wrote:
> Hi Robin and Tyler,
>
> Another important point that we discussed before when powerbox first
> came up was to ensure that we can cover-off some of the basic abuse
> cases (as outlined here:
> http://dev.w3.org/2009/dap/policy-reqs/#abuse-cases ).
>
> Would it be possible to show how powerbox can handle those?
>
> Thanks,
>
>
> David.
>
> -----Original Message-----
> From: public-device-apis-request@w3.org
> [mailto:public-device-apis-request@w3.org] On Behalf Of Robin Berjon
> Sent: 01 June 2010 16:07
> To: Tyler Close
> Cc: public-device-apis@w3.org
> Subject: Re: [Powerbox] New draft based on further collaboration and
> prototyping
>
> Hi Tyler,
>
> On May 27, 2010, at 00:41 , Tyler Close wrote:
>> With the help of Sony Ericsson and Mozilla Labs, we have updated the
>> Powerbox proposal to address a wider array of use-cases and
>> implementation environments. This new draft reflects feedback we
>> received on the initial proposal, discussions with potential
>> implementers and application developers and prototyping work on Chrome
>> and Android.
>
> Thanks a lot for this update, it is most interesting. Reading through it
> I find that most of my comments are of a rather editorial nature, and as
> such I will get back to them later. Most importantly I find that this
> draft is much clearer and presents a better defined approach to the
> problem.
>
>> The current version of the Powerbox spec is ready for wider
>> prototyping work and we look forward to collaboration and feedback
>> from this WG. We would like to see the Powerbox become a W3C
>> Recommendation from this WG.
>
> I agree that this would be a good path to follow. The first step is to
> give it a home in CVS. I believe that you already have an account on
> dev.w3, so the simplest thing is probably that you add a "powerbox"
> directory to http://dev.w3.org/2009/dap/ and place it there. The next
> step would be to agree on what makes the draft "good enough" for a First
> Public WD. Apart from general consideration about quality and pubrules
> which you already know and which I'm not worried about, a general rule
> of thumb which we use in this WG is that ideally a FPWD ought to be
> roughly and to the best of one's guesses feature-complete (though of
> course it doesn't need to be perfect :) The reason for this is that it
> provides somewhat better protection against IP issues for everyone. If
> you think we're roughly there, then we can issue a call for consensus to
> publish the document. We'll deal with the delicious vagaries of
> Rec-track life afterwards.
>
> Process question for Dom: do editors listed on a draft have to be
> formally members of the WG? The companies listed already are, so my
> understanding is that we're covered IP-wise.
>
> To make sure that everything is in the clear, at the last F2F the group
> agreed on what we call informally "the Prague Doctrine"[0], which is
> essentially that we didn't want to pre-emptively decide between
> tradition/JS/host object and REST/Powerbox implementations. This means
> that we endeavour to produce APIs that can be bound to both views, but
> that WG doesn't wish to dedicate a lot of bandwidth to the wiring of
> those bindings (since this essentially means not spending a lot of
> telecon time on them, I doubt it will prove to be an issue though). As
> part of this decision I've offered to create a REST/JSON binding for
> WebIDL so that the mapping would be consistent. To date this has
> essentially been about me scribbling stuff down and tossing it into the
> trashcan but I might have a new take - either way suggestions welcome!
>
> Note that if other editors need access to CVS, they should email Dom
> offlist with their SSH pubkey (and CC me).
>
> Thanks a lot!
>
> [0]
> http://lists.w3.org/Archives/Public/public-device-apis/2010Mar/att-0154/
> minutes-2010-03-16.html#item04
>
> --
> Robin Berjon
>  robineko - hired gun, higher standards
>  http://robineko.com/
>
>
>
>
>
>



-- 
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html

Received on Tuesday, 1 June 2010 17:55:53 UTC