Re: Scientific Literature on Capabilities (was Re: CORS versus Uniform Messaging?)

On Wed, Dec 16, 2009 at 9:25 PM, Ian Hickson <ian@hixie.ch> wrote:

> A concrete example of the example I was talking about is Google's Finance
> GData API. There's a fixed URL on A (Google's site) that represents my
> finance information. There's a site B (my portal page) that is hard-coded
> to fetch that data and display it. I'm logged into A, I'm not logged into
> B, and I've told A (Google) that it's ok to give B access to my financial
> data. Today, this involves a complicated set of bouncing back and forth.
> With CORS, it could be done with zero server-side scripting -- the file
> could just be statically generated with an HTTP header that grants
> permission to my portal to read the page.
>
> ...
>
> As a user, in both the finance case and XBL case, I don't want any UI. I
> just want it to Work.
>

Yet you must go through a UI on site A to tell it that it's OK to give your
data to B.  Obviously this step cannot be altogether eliminated.  What I am
suggesting is a slightly different UI which I think would be no more
difficult to use, but which would avoid the need to hard-code.

In fact, I think my UI is easier for users, because in all likelihood, when
you decide "I want site B to access my data from site A", you are probably
already on site B at the time.  In your UI, you have to navigate back to A
in order to grant permission to B (and doesn't that also require
copy-pasting the host name?).  In my UI, you don't have to leave site B to
make the connection, because the browser remembers that site A provided the
desired capability and thus can present the option to you directly.

The down side is that I don't know how to implement my UI in today's
browsers.