Repost of my comments originally sent to a smaller group:<div><br></div><div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">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.)<div>
<br></div><div>Misc comments:</div><div><br></div><div><div>- 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?</div>
<div><br></div></div><div>- 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.</div>
<div><br></div><div>- 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.</div>
<div><br></div><div>- Maybe type names should be identified by URLs of type definitions.</div><div><br></div><div>- 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.</div>
<div><br></div><div>- 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.</div>
<div><br></div><div>- Are grants revoked automatically when the requester site is closed? I'd argue that this is usually -- but not always -- desirable.</div></span><br><div class="gmail_quote">On Wed, Feb 10, 2010 at 11:46 AM, Mark Seaborn <span dir="ltr"><<a href="mailto:mseaborn@chromium.org">mseaborn@chromium.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">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].<br>
<br>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.<br>
<br>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:<br><br><a href="http://plash.beasts.org/wiki/WebPowerbox" target="_blank">http://plash.beasts.org/wiki/WebPowerbox</a><br><br>The aim is to solve this "previously unsolved problem" of authorisation for both local devices and non-local services.<br>
<br>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.<br><br>Cheers,<br>Mark<br><br>[1] <a href="http://lists.w3.org/Archives/Public/public-device-apis/2010Jan/0061.html" target="_blank">http://lists.w3.org/Archives/Public/public-device-apis/2010Jan/0061.html</a><br>
<br>
<br>_______________________________________________<br>
cap-talk mailing list<br>
<a href="mailto:cap-talk@mail.eros-os.org">cap-talk@mail.eros-os.org</a><br>
<a href="http://www.eros-os.org/mailman/listinfo/cap-talk" target="_blank">http://www.eros-os.org/mailman/listinfo/cap-talk</a><br>
<br></blockquote></div><br></div>