[cap-talk] Granting access to web services

[Mark Seaborn]

On Wed, Feb 10, 2010 at 1:12 PM, Kenton Varda <temporal at gmail.com> wrote:

> Misc comments:
>
> - How is registering a provider initiated?  Hopefully we don't just pop up
> a dialog box on the web site's whim.  I have been imagining that the site
> would provide some sort of a widget which represents the object, and the
> user must click on that in order to initiate the provider registration
> process.  Similarly, the requester site would have some sort of widget
> representing a "socket" for an object, and the user would click on it in
> order to initiate the process of fulfilling the request.
>

Yes, the widget would be a DOM element, implemented by the browser and
rendered as a button.

For requesting a service, we can use <input> with a new "type" attribute
value, or use "type=file" so that it falls back to file upload on browsers
without powerbox support.

For registering a provider, <input> is not appropriate.  <input> works for
file upload but there is no equivalent for file download, so I think we'd
want a new element, but I'm not sure what to call it.  Probably not
"<output>". ;-)

We should provide Javascript libraries implementing these widgets -- maybe
> the scripts would actually be hosted by the powerbox server?
>

I'm not sure what you mean here.  If the widgets aren't implemented by the
browser (in the ideal case, not a prototype), what would a library
implement?



> - In addition to the UI you describe, we should support drag-and-drop
> direct from a provider site to a requester site.  As with drag-and-drop for
> opening files, power users will find this more convenient than going through
> "save" and "open" dialogs.  This is straightforward to implement if the
> provider and requester use widgets like I described in the previous point.
>

I was thinking that the request-service and register-provider buttons could
be overloaded so that not only can you click on them to open a dialog, you
can also drag-and-drop one onto the other to perform a grant.

This would work fine for non-interactive providers.

I am not so sure about interactive providers.  We could open a new tab after
the drag-and-drop, but this seems like it would be disorienting.  There is
some precedent for requiring further interaction after a drag-and-drop:  on
Windows, right-button-dragging a file opens a menu to choose between Copy,
Move and Create Shortcut.  However, that is only a small menu.

I must say I have a hard time imagining how cross-tab drag-and-drop can be
made easy-to-use.  Wouldn't the user have to arrange two browser windows
side by side?  Or would the browser provide a shortcut to open two tabs side
by side in the same window?  I don't think I've ever used drag-and-drop
between browser tabs.  The last GUI I used that used drag-and-drop
extensively like this was RISC OS.


- The powerbox should provide a UI for visualizing all established
> connections between requesters and providers, showing activity occurring on
> these connections, and allowing the user to revoke connections.
>

In my proposal the browser/powerbox does not mediate the connections, so it
cannot show activity on those connections.  In fact, it cannot enforce
mediation, because the two parties involved have network access and can
arrange to bypass any mediation.

So it's up to the provider to offer a review and revocation facility, which
can be reached via its info_url.  I think this is more useful than putting a
revocation facility into the browser/powerbox, because the provider can
display the information in the form that is most appropriate to the service
it provides.  If a provider doesn't offer revocation, it's possible to wrap
it to make a provider that does.

That said, it may be useful for some services to voluntarily be mediated
through the browser/powerbox, so that they can be revoked automatically when
the tab is closed, e.g. for tab-lifetime-limited camera access.

Also, the powerbox can keep a log of all the grants it has established, even
if it can't revoke them itself.


- Maybe type names should be identified by URLs of type definitions.
>

Maybe.  The main question I have is whether we should attempt to display
service types to the user, to help them understand how provider filtering
works.


- Obtaining the site's powerbox web key:  This is so that we can force
> default pet names to begin with the site's domain name, right?
>

Yes.


> This sounds like a case of the site having ambient authority, which
> ironically means CORS could provide the answer:  the site could make a CORS
> request to the powerbox to get the web key, and the powerbox would use
> Access-Control-Allow-Origin to ensure that a site can only obtain its own
> key.
>

Yes, that could work for a prototype.  The site would need a way to discover
the (guessable) URL of the powerbox server; the URL could be stashed in the
DOM using Greasemonkey.

This shouldn't be a long-term solution, of course, because we'd ideally want
> to avoid relying on CORS in any way.
>

Yes, the long-term solution is a DOM element.


- Do we need to require provider URLs to be unguessable?  What if the
> service being provided is really intended to be accessible to all?  How
> about we don't make any particular requirements on the provider URLs, but
> suggest that they should be web keys if the resource is intended to be
> private.
>

That sounds fine.  I wasn't going to suggest that anyone other the URL's
creator checks that the URL is sufficiently random.  I don't know if there
is a way to do this anyway.

There may well be public services, e.g. a public web cam that provides the
same API as a local web cam.

There might also be public, shared provider web-keys which generate new,
private service web-keys every time they are invoked.  I can't think of a
good example at the moment though.  (The list() constructor in Python, which
creates a mutable list, is an example in a programming languages context,
but this does not create revocable objects.)


- Are grants revoked automatically when the requester site is closed?  I'd
> argue that this is usually -- but not always -- desirable.
>

See my comments above.

Cheers,
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20100211/cb7620ca/attachment-0001.html