[whatwg] Cross-domain components

[Ian Hickson]

On Sun, 29 Apr 2007, Henrik Gulbrandsen wrote:
> On Sat, 2007-04-28 at 02:43 +0000, Ian Hickson wrote:
> > > 
> > > This could work for a single widget service, but breaks down if we 
> > > imagine multiple popular components of this type that should follow 
> > > a user's preferences even when surfing from a cybercafé
> > 
> > This could work, you just need the original iframe to show a login 
> > page instead of the widget, and then once the user has logged in, use 
> > the preferred widget.
> 
> The keyword here is "multiple". I was imagining a scenario where this 
> kind of integration becomes popular, and the user has not only the given 
> calendar widget, but also an email launcher, a spreadsheet manipulation 
> widget, a website preference negotiation component, a payment service 
> provider widget, and a context-sensitive application toolbar integrated 
> with the main menu of a given site.
> 
> All of these might not be used on a single site, but it would still be 
> very annoying to have a separate login for each and every component. 
> That is why I mentioned the "global login" option in my original post. 
> With a single login per browser session, this generalized mashup would 
> actually scale; it's also useful as a general cross-site login method.

I agree, but this doesn't have to be implemented in the spec. Distributed 
decentralised single sign-on is addressed by things like OpenID. The 
system described above, with iframes pointing at widget meta-providers and 
having them redirect to widgets after login can still be done with a 
single login step without further help from the spec.


> One way to do this would be to have a URI-Specific Profile ID that acts 
> as the combined username/password secret for a specific web resource. 
> Let's say that the client looks for a string like "(*URISPID*)" in all 
> loaded URLs. If the string is found, it is replaced with an MD5 hash of 
> a local user secret (username/password) combined with a part of the URL. 
> If the client doesn't support this feature, the "(*URISPID*)" part is 
> left unchanged, so the server can fall back to a traditional login page.
> 
> For example, an access to
> 
>   https://www.example.com/interfaces/calendar/v1?id=(*URISPID*)&option=1
> 
> could have its "(*URISPID*)" part replaced by
> 
>   hash(hash(username + ":" + password) + ":" + base_url)
> 
> where base_url = "https://www.example.com/interfaces/calendar/v1".

That's possible, but I think it's better to decouple the solution from 
the HTML5 language here, in the manner of OpenID and others. We want to 
provide a platform on top of which this kind of thing can be built.


> > > Item 3 highlights a privacy leak in the cross-document messaging API 
> > > specified in the current WA1 draft. It's clear that postMessage() 
> > > was not intended for this kind of scenario, since the domain 
> > > attribute will completely break any attempt to hide the two domains 
> > > from each other.
> > 
> > Hm, interesting. It's true that the current design leaks the domain. 
> > You could get around that by having messages proxied through the 
> > original redirecting domain, though; no privacy leak there since the 
> > original domain is know to the embedding page and the chose widget 
> > provider has to be known to the middleman already.
> 
> Well, in principle you don't want those messages to be exposed to the 
> redirecting domain either, but I suppose that the interface publisher is 
> more trusted than the other domains. Since the interface is central, any 
> attempt to pass private data back to the server would be noticed quickly 
> by someone. Besides, if the redirecting domain isn't trusted, it can use 
> the proxy iframe anyway, although we are actually expecting a redirect.
> 
> This means that your workaround is most likely acceptable for this case, 
> although I'm slightly worried that it might not cover other scenarios. 
> In general, it's probably safer if the author must request to have the 
> domain visible when it should be checked, rather than the other way 
> around, since he may not remember to hide it when that is needed.
> 
> However, I don't feel strongly about this, since I don't know if domain 
> hiding will ever be strictly necessary. Let's just keep it in mind, so 
> we don't make this hole in the same-origin policy bigger than it needs 
> to be. Perhaps a hide/show flag argument to postMessage() is worth the 
> extra trouble, just to stay on the safe side.

It's something to bear in mind if there's a need, I agree. I don't think 
we need it in the first version, though.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'