Re: Tying "form-filler support" to HTTP authentication

I think this should be as lightweight as at all possible -- if
one could get there with just a few class and id parameters and
maybe a bit of material in the <head/> part of an HTML page,
without even touching the DTD, that might in fact be best; the
upgrade path for older browsers would be to simply submit the
credentials (if entered by the user) by HTTP POST.

At the same time, this approach might be easier to extend and
change than an approach that adds new tags.

From what you suggest, I think there are two main situations
that we'd need to think about:

- Mechanisms like HTTP Digest Authentication that keep the user
  name / password paradigm, where the same form can be used for
  falling back to HTTP POST (and cookies), and for entry of
  credentials for the protocol-level mechanism.

- Mechanisms like Infocard, where the HTML form might be a
  fallback, but we basically want it to say "please ignore me
  if you know how to do X."

Regards,
-- 
Thomas Roessler, W3C   <tlr@w3.org>





On 2006-05-24 13:53:23 +0000, Mike Beltzner wrote:
> From: Mike Beltzner <beltzner@mozilla.com>
> To: Thomas Roessler <tlr@w3.org>, public-usable-authentication@w3.org
> Date: Wed, 24 May 2006 13:53:23 +0000 GMT
> Subject: Re: Tying "form-filler support" to HTTP authentication
> X-Spam-Level: 
> 
> So, essentially, you're talking about standardizing the
> markup that Microsoft is proposing with its InfoCard system,
> and creating a lighterweight (yet compatible) subset of tags
> that describe that a form is present which -- should the
> user agent support it -- should use a client side mechanism
> for securing the form contents. If the system supports
> InfoCard, that infrastructure would get called, if the
> system has its own form authenticator and filler, then it
> could use that. 
> 
> I like the approach, in general, I just think its important
> to be mindful of the work that Sxip and MS have done in
> coming up with architectures to support the authentication
> and transfer of credentials and information to ensure that
> we don't take a step sideways as opposed to a step forward. 
> 
> cheers,
> mike 
> 
> -----Original Message-----
> From: Thomas Roessler <tlr@w3.org>
> Date: Wed, 24 May 2006 10:56:44 
> To:public-usable-authentication@w3.org
> Subject: Tying "form-filler support" to HTTP authentication
> 
> 
> What we called "form-filler support" in New York essentially
> boils down to enabling user agents to reliably recognize form
> fields that are used to enter credentials.  Having additional
> markup for authentication-related forms (or microformat-like
> annotations) would serve two main use cases:
> 
> - User agents can reliably manage passwords (and, possibly,
>   other credentials).
> 
> - User agents can grab the content of these fields and not
>   submit it through HTTP POST, but use it as credentials for
>   whatever HTTP authentication mechanism is to be used.
> 
> (Each of these would need slightly different semantics in terms
> of mark-up.)
> 
> Additionally (and essentially "for free"), user agents could
> use this mark-up to trigger whatever additional user interface
> mechanisms and rituals they might come up with.
> 
> I'd very much welcome feed-back about this general approach as
> a scope for one particular direction of further work.
> 
> PS: I'm in Edinburgh at WWW 2006; if you want to talk about
> this in person, feel free to drop me a line.
> 
> Regards,
> -- 
> Thomas Roessler, W3C   <tlr@w3.org>
>

Received on Wednesday, 24 May 2006 15:45:35 UTC