How can 401 responses get tied to a Launcher App

[bblfish]

Issue 31: Accessing NonRDF-Sources directly via the browser brings up the question as to how a 401 returned by resources to browsers that don't have the capability to read wACLs, can then allow the user to get access to the resource.

For passwords the server can return a WWW-Authenticate header, which will get the browser to open a request for passwords. For other authentication systems, a web page is usually returned, allowing the user then to enter an OpenID for example. But this last one would not be able to allow the user to take advantage of the ACL logic of his Launcher App, and so require the user to choose haphazardly one of OpenId providers, even if none of those fit the ACLs.

Q: What methods could help here?

It would be nice to see how this could be tied to a LauncherApp, so that further informed authentication decisions can be made by it. Could a browser plugin help?

[bblfish]

So the current way to do this would be for the resource returning a 401 to return a page with

1. a set of relevant WWW-Authenticate headers
2. an html page with a form where the user can enter say a URL (perhaps an OpenID)

So for 1. a Browser Plugin could be very useful for extended WWW-Authenticate headers - and perhaps even to improve the UI of the standard existing ones - making the life for the user much easier.

Of course having something like 2. as a fallback would be necessary. One could start by considering if it would be possible for the user to enter a URL to the LauncherApp so that it can start and retry access to the document?