tabs and state, REST vs documents

One of the traditional ways to handle authentication per tab. is to ignore
the browser. The document exchanges do the work, per tab, then - using the
usual document-centric verbs.

 

In
http://weblogs.asp.net/cibrax/archive/2009/03/06/brokered-authentication-for
-rest-active-clients-with-saml.aspx, one can play with a combination of
religions, webid included. It's a restful STS (vs the "evil" SOAP). It does
POST (the evil) XML documents, though (sorry, could not be totally pure). It
also mints a signed SAML token document (more XML evil documents, true),
that is attached to the www-auth header for additional RESTful service
interactions.

 

The code shows how to capture the cert supporting the signed SAML document,
at a RESTful endpoint, in an interceptor. Obviously, one takes the webid
validation mechanism one has (already applied to endpoints consuming https
client authn certs), and applies it there, to do the sparql ping, etc etc.
Any windows programmer with 1 year schooling in programming can do this.

 

What the REST stuff does in generating HTML and javascript to frame up - per
tab - a per-user- indication of logon state (per site) is ..up to it,
obviously.

 

If occurs to me though, that perhaps the  javascript in that document could
at least be "informing" the browser container (of tabs, and thence pages),
what it is doing in setting user context - per tab. Then the browser might
ALSO learn to re-present what the site is indicating, as user identity. Just
like Opera shows the client cert (on the address bar), perhaps Opera could
be showing what the site has verified and accepted as webid identity __per
tab__ (after all the SSL negotiations.) . If its tied to the address bar,
then its relating to the current tab in focus. Why? Because the javascript
invoked by the browser, as obtained the REST service recently having done
webid validation, "told" the browser what to say.

 

Now, ideally, the browser would pop up a panel, having itself pulled the
foaf card (in one of n different RDF dialects), and be RDF driven. But,
that's not reality (for politics, a decade ago). It's never going to happen,
any time soon. The Romans will defeat Hannibal, at Carthage, first (urr.).
But, one COULD imagine a fixed XML structure, perhaps based on xml-dsig,
that is just a "signal" between site and browser (where site was responsible
for doing the RDF bit.). Since site is already doing the RDF bit (that's
webid), perhaps there is a win win here.