Subject: Client Interaction and Automation (was Re: [dix] Review of draft-merrells-dix-00.txt)

From: Nick Ragouzis <[email-masked]>
Date: Mon, 20 Feb 2006 18:17:09 -0800

> Dick Hardt <[email-masked]> wrote @ Mon, 13 Feb 2006 11:02:38 -0800
> On 11-Feb-06, at 3:17 PM, Eric Rescorla wrote:
> 
> > Use of Javascript
> > Section 5.10.2.1 reads:
> >
> >    The Membersite sends a fetch-request message to the Homesite  
> > through
> >    the User's client via a redirected HTTP POST to their Homesite
> >    Endpoint URL using JavaScript to autosubmit the form.
> >
> > I appreciate the rationale for this: you want things to work with
> > dumb clients but given that Javascript isn't any kind of IETF
> > standard--it's hard to see how we could require it in an IETF
> > standard. ECMASCript, perhaps. Even then, specifying this kind
> > of implementation detail is the kind of thing that IETF typically
> > stays out of. I appreciate that this is also a wire protocol issue,
> > but given that there's no specification of the exact JavaScript
> > incantation, it's not clear it makes sense to specify only
> > the language.
> 
> The protocol works without the ECMAScript, the user would need to  
> click another button to continue on with the exchange. The 
> ECMAScript  
> provides a more seamless use experience since a POST cannot be  
> redirected, and we did not want to limit the data to what could sit  
> on a URL, as well, did not want the data to have to be exposed by  
> being on a URL. As noted in another email, an enhanced browser does  
> not need to the ECMAScript. We see this as a boot strap method.
> 
> wrt. how it is positioned in the ID, I agree it is an implementation  
> detail. How would you suggest that implementation hints like 
> this are  
> communicated?
> 
> -- Dick

Two things for me here.

1. This underscores that the FIRST consideration is the user 
   interaction at this interface. That it *can* be automated
   doesn't relieve us of thinking fully about how it works when
   it isn't automated.

   This will unfold in an environment of wide diversity, to say
   the least. Who would be surprised if when plug in/extension
   makers, or browser designers, look at this they don't decide
   it is part of the same cloth in which users are asked to
   agree that a particular certificate should be Green in their
   address bar, or that a particular picture should be presented
   in association with a (selectable) range of sites? And so on.

   Even among the "dix-loyal," there will be a wide range of
   approaches to presentation, including unintended (or intended)
   confusion.

   If we elevate the true basis here, then surely we don't want
   yet another badly, partially, often-ineptly, followed way for
   users to see security prompts and dialogs.

   I suggest this is an effort worthy of specific attention.

2. The specification of ECMAScript does not belong in the 
   normative part of this specification, IMO.

   In the first instance, it is a matter between the Home/Membersite
   and their common user. Each might do something different, 
   according to the interaction they intend.

   In the second instance, what we need is the general requirement,
   without regard to implementation, buttressed by a method for
   judging compliance. The general requirement tends to things that
   any client service (presenting to the user at least a dumb
   HTTP client) must provide, including security and timing and
   presentation/affordances: whether on mobiles or on grid nodes. 
   This, then, could even be implemented as an automated service of 
   the browser, perhaps as a declared capability. The compliance
   method prescribes the appropriate tests. These are tests, I 
   would think, that even a user could provoke, to be assured of
   the correct operation of this 'magic' with that all-so-valuable
   identity.

   The ECMAScript, or Java, or VBScript, or JScript, or Postscript,
   or whatever tools will realize this redirection when fully or
   partially automated (as we look to the future) ... well some
   implementation guidelines could be provided as examples. If
   ECMAScript (and JavaScript) happen to be the most broadly
   deployed, we're none-the-worse off.

--Nick   

_______________________________________________
dix mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dix