dotgnu-auth
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Auth]I think I have it... (browser auth interaction: simple and clean)

From: John
Subject: [Auth]I think I have it... (browser auth interaction: simple and clean)
Date: Thu, 11 Jul 2002 10:37:49 -0400
User-agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0) Gecko/20020530
In the last meeting we were concerned about the easiest way for designers to link auth services to both a browser or a webservice. Now for a service this would logically be an XMLRPC or SOAP request that can be recognized by the connecting service and spawned to the DotGNU auth component. Web pages however pose a special problem because: 

1) the interactor is human being using a client, not a client program
2) the interactor makes a decision to authorize or not authorize and may do so at any time during the transaction 3) the webservice is abrogated from accessing profile information until the user authorizes 4) the webpage accessible services are largely already written in HTML and though new services myay surface in other markups, HTML will remain popular for quite sometime. We need to easily link into the existing infrastructure.
I've been largely opposed to plugins in the past, because, quite frankly I couldn't make them work in either the FrePort or MACS context and certainly not in a unified context. I've had new insight and I think plug-ins, which have been suggested many times in the past, would be acceptable, so long as they do not render anything within the current page context. Consider the following methodology: 

The HTML page will contain in the <head>
<link type="application/x-gnuprofile" href="https://the.service.uri.com/link/to/requested/info.gpro";>
All browsers allow us to add media types as plugin, or in the case of IE: Active-X. The x-gnuprofile file would contain the necessary definition for authorization with the page in question. The browser would by following the basic rules of <link> and would download the x-gnuprofile file and then pass this data to the plugin? The file would contain a static version of the very same commands used in the XMLRPC or SOAP call used by a peer to peer webservice. If the user has not logged into their profile; the plug-in pops a window and asks "[Site] requests you to authorize" with appropriate gadgets to accomplish that task. If the user is already logged in the user will be asked whether they wish to authorize the transmission of all or part of their profile (with confirmation on sensitive transmissions) to the service. The user can also be given an opportunity to switch their role at this point; roles save users from having multiple accounts and I strongly emphasize them in FrePort. The best of all from our standpoint has to be that there is no massive need for support from the web developer beyond writing his gpro, which could be a wizard. Greatest plus for the web designer: no "login gnu" button need be allocated on the web page. They can keep their existing layout, look and feel.
If you think about the proposal, we meet all the requirements of the above scenario.
Of course, all the above is contingent on politics as well as technology. Will we be required to register the MIME type and extension with the appropriate authority, or submit for approval our novel use of <link> to the W3C? Will we be required to interact with some search registry of plugins and would the powers-that-be try to block our access? I can think of other political questions not the least of which would be to recruit an ActiveX programmer, but the main question for now would be "Does this solve the browser problem?" 

John Le'Brecage
reply via email to
[Prev in Thread] Current Thread [Next in Thread]