Services that require login

[James Henstridge]

While investigating the Web Intents specification, one area I had some
questions about was services that require authentication by bouncing
the user through a login page.

When the user has already authenticated to the site there is no
problem. But if they are unauthenticated (e.g. if their session
cookie has expired), there are two possible problems:

1. When the user eventually gets to the service page, the intent won't
load because it fails the verification test:

verified = (window.history.length == 1) ? true : false;

So even if window.name is still intact and holds the intent data, the
Javascript shim will ignore it.

2. If we're using a login provider that supports intents itself (e.g.
as suggested in http://usecases.webintents.org/post/7928392777/usecase-log-in-stack-overflow),
the login page might consume the intent and blank out window.name
before the service page loads.


At least the first issue sounds like something that would be a fairly
common problem, and it isn't clear how to handle it with the current
code. The second is more of a theoretical problem, but I imagine it
could also apply if a service required an extra page load to complete
before it could respond to the intent.


James Henstridge.

[Mike Hanson]

Hi, James - Mozilla has a proposal to address the authentication-and-session management problem, which is currently in our almost-the-same-as-Intents design document, here:

https://github.com/mozilla/openwebapps/blob/develop/docs/ACTIVITIES.md

Our goal is to support multiple-credentials-per-intent-provider with enough UI to let the user pick a useful one. The specific use case we were thinking of there was, "share as this twitter ID" or "send with this Gmail account".

Your feedback would be very welcome.

Best,
Mike
--
Michael Hanson, Mozilla Labs
mha...@mozilla.com

[Paul Kinlan]

Hi James,

The shim might have some of these problems, I didn't want the window.name to be present throughout the life of the window because we can't clear it down for apps that are on different domains (yet).  After some discussion, the window.intent object should be available to any page in that window on the same domain/or url for full implementations by the UA of web intents.

This will allow you to bounce the user through an authentication process without the external sites being able to access the data, and then when you return to your web app you will still be able to access it.

For point 2, the idea behind the authentication intent is to simply start off the authentication flow with a service - this use case needs to be fleshed out more, but is primarily for a site like stackoverflow to be able to list only the authentication providers that a user actually uses rather than the entire gamut of services.  The idea being if you host your own SP then you would want it to always appear but stackoverflow will never include that in the list of supported SP's. 

P

--
Paul Kinlan
Developer Advocate @ Google for Chrome and HTML5

G+: http://plus.ly/paul.kinlan
t: +447730517944
tw: @Paul_Kinlan
LinkedIn: http://uk.linkedin.com/in/paulkinlan
Blog: http://paul.kinlan.me
Skype: paul.kinlan

[James Henstridge]

On Sep 14, 1:19 am, Paul Kinlan <paulkin...@google.com> wrote:
> The shim might have some of these problems, I didn't want the window.name to
> be present throughout the life of the window because we can't clear it down
> for apps that are on different domains (yet).  After some discussion, the
> window.intent object should be available to any page in that window on the
> same domain/or url for full implementations by the UA of web intents.
>
> This will allow you to bounce the user through an authentication process
> without the external sites being able to access the data, and then when you
> return to your web app you will still be able to access it.

Okay. Would this still work if the authentication process took the
user off of the domain before bringing them back to the initial domain
the intent was targeted at? For my app, the login process goes
something like:

1. User visits page
2. Session cookie doesn't indicate user has logged in, so user
redirected to login page.
3. Login page starts an identifier select OpenID authentication
request to the central auth server.
4. User interacts with OpenID provider.
5. On successful authentication, session cookie set up and user
directed back to the original page.

So any system that cleared the intent as soon as we switch domain
would also cause a problem.

> For point 2, the idea behind the authentication intent is to simply start
> off the authentication flow with a service - this use case needs to be
> fleshed out more, but is primarily for a site like stackoverflow to be able
> to list only the authentication providers that a user actually uses rather
> than the entire gamut of services.  The idea being if you host your own SP
> then you would want it to always appear but stackoverflow will never include
> that in the list of supported SP's.

I guess the part I missed from my original message is that I'm also
using OpenID as a federated identity system
(http://login.ubuntu.com/). If the idea of using intents to advertise
identity providers becomes popular, it is exactly the kind of thing
they might get interested in.

And the obvious place for an identity provider to advertise its
intents would be on the login or authorisation pages, which would also
be hit if a user tried to use my intent provider but had not logged
in.

These pages probably wouldn't be the target page for the identity
provider's intents though, so if there was a way to register intents
on a page without consuming them then things could still work out.

James Henstridge.

[James Henstridge]

On Sep 14, 12:05 am, Mike Hanson <mhan...@mozilla.com> wrote:
> Hi, James - Mozilla has a proposal to address the authentication-and-session management problem, which is currently in our almost-the-same-as-Intents design document, here:
>
> https://github.com/mozilla/openwebapps/blob/develop/docs/ACTIVITIES.md
>
> Our goal is to support multiple-credentials-per-intent-provider with enough UI to let the user pick a useful one.  The specific use case we were thinking of there was, "share as this twitter ID" or "send with this Gmail account".
>
> Your feedback would be very welcome.

So looking at that specification, the answer seems to be to completely
change how we handle authentication. While it might end up being able
to provide a better user experience, I was hoping for something that
would work with existing systems.

I've got a lot more freedom to experiment with new technologies like
web intents when it is constrained to one or two pages on the site
than when it requires me to update the authentication system. I
suspect the same would be true for a lot of others considering
adopting this technology.

One other thing I notice from this specification is that it is lacking
a way to register services that are provided by other URLs. The main
use case here is when the service is provided by a URL that the user
might not otherwise visit. If I have another page on the site that
all my target users will visit, then it would be useful if I could
perform the registrations there. I realise that the current Web
Intents implementation probably goes a bit far by allowing you to
register intents for other sites without their knowledge, but it would
be nice to be able to at least perform registrations on behalf of
other pages that would be considered the same origin.

James.

[Tyler Close]

I think the general problem with this login use-case is that Web
Intents currently don't nest, as in an intent handler can't itself
launch an intent. If they could nest, an intent handler could launch a
login intent and the problem is solved. RPH does support nesting and
so doesn't have this problem. The intent handler delays doing an
opener.postMessage() until after it has completed a login intent. (The
Introducer also enables this kind of nesting).

I believe nesting of intents will be very useful beyond just the login
case, but login seems like a good example to drive the discussion.

--Tyler

[Paul Kinlan]

Hi Tyler,

What do you mean nest?  Do you mean keeping the intent data on the window for the app in the same domain?  If so, then this is purely a shim issue at the moment, and clarification in the spec to say when the intent data should be available.

If the intent data is available to the app in the same window on the same domain then this is not an issue with WI.

P

[Tyler Close]

On Wed, Sep 14, 2011 at 11:42 PM, Paul Kinlan <paulk...@google.com> wrote:
> Hi Tyler,
> What do you mean nest?

I mean an intent handler that is in the middle of handling an intent
(hasn't called intent.postResult() yet) can launch a new intent and
get a response. Since Chrome Web Intents uses a special browsing
context to display the intent handler, it is not possible for the
intent handler to launch a new intent: the special browsing context is
already occupied.

--Tyler

[Greg Billock]

On Thu, Sep 15, 2011 at 9:28 AM, Tyler Close <tjc...@google.com> wrote:

On Wed, Sep 14, 2011 at 11:42 PM, Paul Kinlan <paulk...@google.com> wrote:
> Hi Tyler,
> What do you mean nest?

I mean an intent handler that is in the middle of handling an intent
(hasn't called intent.postResult() yet) can launch a new intent and
get a response. Since Chrome Web Intents uses a special browsing
context to display the intent handler, it is not possible for the
intent handler to launch a new intent: the special browsing context is
already occupied.

It isn't clear what chaining intents ought to look like for an inline disposition. We'll have to deal with that at some point, and haven't yet, really. For a new page disposition, I'm still not sure it's a good idea, but there's nothing planned at present to forbid it.

I suspect that generic app composability is an edge case that is worth thinking about and hopefully we can figure out how to avoid making impossible, but isn't in the sweet spot for intents. That is, my view of the trade-offs is that if it turns out that a chaining-friendly UI ends up being more complex or error-prone, then we should discard it.

Similarly, it'd be awesome if intents turn out to be a big contribution to the identity puzzle, but I think linking their definition too closely to that very hard problem is a mistake. Perhaps the biggest contribution of intents there will be being able to make loosely coupled identity prototypes along the way towards a more robust browser-managed identity solution. It's hard to say, but I think we'll end up thinking unproductively if we attempt to solve that problem as a prerequisite to handling intents. They're obviously related in that a strong identity solution will make intents more awesome, and perhaps an awesome identity solution will end up making use of intents-like functionality, but linking their fates is a risky path.

-Greg

[Mike Hanson]

Hi, James -

Hm, the goal was to make it work with your current auth scheme - but to give you a way to handle multiple accounts. Perhaps our intent (hah!) was not clear.

The basic idea was that we create your iframe and fire the request at you - and that you do whatever it is you do to check the session, and if that doesn't work, you fire back a "auth required" message at us, and we do a popup window pointing at your "login" intent path. You could potentially do redirects, federation, whatever inside that window, so long as, at the end of it, you call a method that says, "okay, login's done, remember this blob for me so I can keep track of it".

That blob is just so we can pop a picker that can say, "Share Service X -- JaneWork", "Share Service X -- JaneHome". But in the simple, session-cookie based case, you don't need to do any of that. In the simple case, it would let us display a username on the intent picker, which would be pretty nice.

(catching up with the rest of the thread here - I'll try to weigh in at the tail)

mh

[Paul Kinlan]

On the specific subject of chaining intents, like Greg mentions, there is nothing that forbids it. I can launch an app, which launches an app.   It is certainly possible to do that in the shim.

A use-case would be, Edit an image (so launch an intent), Share image in the edit app - which I believe we have an a demo (that will be launched soon for).

P