> Dick Hardt <[EMAIL PROTECTED]> 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 protected] https://www1.ietf.org/mailman/listinfo/dix
