[cap-talk] Granting access to web services

[Kenton Varda]

Repost of my comments originally sent to a smaller group:

Nice, this looks like pretty much exactly what I was thinking of.  (BTW, if
it wasn't clear, I'd like to be involved in any discussions you have about
this -- I just won't have a lot of time to implement for a few more weeks.)

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.  We should provide
Javascript libraries implementing these widgets -- maybe the scripts would
actually be hosted by the powerbox server?

- 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.

- 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.

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

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

- 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.

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

On Wed, Feb 10, 2010 at 11:46 AM, Mark Seaborn <mseaborn at chromium.org>wrote:

> There is currently a discussion on the public-device-apis list about the
> idea of implementing access to local devices (such as camera, microphone and
> GPS) as local web services rather than building the functionality into the
> web browser, following a suggestion by Mark Miller [1].
>
> MarkM suggested that this would reduce to the "previously unsolved problem"
> of how to grant one web app access to a service provided by another web app,
> whether local or not.  This problem was the main obstacle to the "RESTful
> local devices" approach.
>
> 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.
>
> There are still some details to be worked out so I thought I'd post here in
> order to capture any brainstorming that might happen, before posting to
> public-device-apis.
>
> Cheers,
> Mark
>
> [1]
> http://lists.w3.org/Archives/Public/public-device-apis/2010Jan/0061.html
>
>
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20100210/a2c760a1/attachment.html