W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

Re: Semi-public resources in Uniform Messaging

From: Tyler Close <tyler.close@gmail.com>
Date: Wed, 9 Dec 2009 15:41:14 -0800
Message-ID: <5691356f0912091541k2ac2f4daj725d995950822b4b@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: public-webapps@w3.org
On Wed, Dec 9, 2009 at 2:24 PM, Ian Hickson <ian@hixie.ch> wrote:
> On Wed, 9 Dec 2009, Tyler Close wrote:
>> >
>> > I think asking users to pass around secret tokens is a non-starter.
>> Users pass around secret tokens all the time, they just don't realize
>> that's what they're doing. I assume your statement above is actually
>> meant to say: "I don't want users to see the secret tokens". That's
>> fine. There are a number of ways of doing the GUI such that the user
>> doesn't see the token. We did just such an example for Maciej's calendar
>> scenario. For the above challenge, you specifically asked about the
>> configuration of the server, not the GUI. We can move on to discussing
>> the GUI if you're saying you have no problem with the server
>> configuration. The permission grant and permission exercise phases are
>> analogous to the previous Maciej calendar scenario, so we can reuse
>> those diagrams for the explanation. Just substitute "feed reeder" for
>> "upcoming event" site, and "read feed" for "add event".
> That still seems way too complicated.
> Here's the UI I want:
>   - User logs into site A (the one with the service).
>   - User visits site B and says nothing unique to site B.
>   - Users sees his data from site A on site B.

If you're willing to tolerate a little bit of implementation
mechanism, I can do you one better on the UI side. From the user's
perspective, the UI will be:

 - User visits site B and says nothing unique to site B.
 - Users sees his data from site A on site B.

Meaning the user won't have to start a login session with site A
before using site B. They can just go to site B and immediately get
full functionality.

For each user:
1. Site B generates an unguessable token and associates it with a user account.
2. A page from Site B does an HTML <form> post of the token to Site A.
3. Server-side, Site A sends a request to Site B containing the token
and the corresponding unguessable user feed URL.
4. Site B stores the feed URL in the user account.
5. From then on, a page from Site B can do a direct GET on the feed
URL. Steps 1 through 4 are a one-time setup.

All of the above is invisible to the user. There are no user actions
required. The implementation is fairly straightforward and the UI is
strictly superior to your ideal UI.


"Waterken News: Capability security on the Web"
Received on Wednesday, 9 December 2009 23:41:54 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:21 UTC