[cap-talk] Granting access to web services

[Dirk Pranke]

On Wed, Feb 10, 2010 at 11:46 AM, Mark Seaborn <mseaborn at chromium.org> wrote:
> With help from Tyler Close and MarkM, I have sketched out a proposal for a
> mechanism by which a user can grant one web app access to a service provided
> by another web app:
>
> http://plash.beasts.org/wiki/WebPowerbox
>
> The aim is to solve this "previously unsolved problem" of authorisation for
> both local devices and non-local services.
>

Hi Mark,

In reading this, I suspect I may have some of the same concerns that
Tyler had about including too-many "cap-talk"-specific technologies
without the obvious reason for them being there. The design doc is a
bit elliptical and, having sufficient context I can reconstruct most of the
design choices but I think it would be preferable to be explicit about them.

The way I looked at the spec, I saw I few different things.

The first was a general powerbox UI flow for new services. While this
idea by itself is pretty straightforward, what you're attempting to do
with it isn't, IMO. Namely (a) you're attempting to make it generic,
(b) you are supporting multiple providers, and (c) you are attempting
to describe a way to register providers. I think it would be good to
motivate each of these decisions and try to give examples that it will
be workable and pleasing.

For example, the genericity of the dialog: access to a camera is
straightforward, but how do we cleanly build a UI that allows for all
of the other uses cases as well? It feels like either you get one
uber-complex dialog, or you get a multi-stage dialog that could
perhaps be too painful for any single use case. By virtue of it being
generic, do we open the risk that the requesting web page has too much
control over the parameters (and hence the user clicking on a single
"GET" button can't perceive the complexity and/or react accordingly)?

For multiple providers, do we believe that this will be a common
occurrence? Or more strongly, that any UI designer will actually allow
someone to be exposed to this choice?

For registering providers, I'm a little hesitant about the whole
concept of multiple providers here. I'm not sure that you can sensibly
paper over the local/remote distinction in the type of resource you're
giving access to. For example, in a camera API, something has to
actually fetch the image. If the provider is local, the image is
local. If the provider is remote (e.g., Picasa), is the browser
responsible for fetching it and then turning it into a real image that
gets uploaded (or handed to the caller)? Also, this assumes that
everyone implements the same service provider API, which seems like a
pretty big assumption.

In the case of choosing between a "live" local image and a previously
stored one (or a "live" GPS location and a fake client-specified one),
it makes sense, but again I'm a bit worried that we'd be building in a
bunch of complexity that would never see the light of day (I'm
thinking of the "accept" attribute on the input type="file" element
here, which AFAIK was maybe only implemented by Opera).

Then, you have the whole petname/webkey aspect of the proposals, which
are somewhat orthogonal.

And the aspects about permission management which is perhaps out of
scope for your proposal.

So, I guess the summary is that there are a lot of aspects of this
design that make me pretty nervous.

-- Dirk