Wrapping Up Proposals

[Josh Hoyt]

On 10/2/06, Recordon, David <drecordon at verisign.com> wrote:
> Agreement? Disagreement?

Generally agreed, though I'd like to see a verdict on IdP-supported delegation.

I think that it's a good idea to put the bar high for putting new
stuff in the spec. The spec has been in the works for a long time, and
as it stands, it adds some useful features. There is no reason that we
can't put out a 2.1 spec if new features are accepted by the community
and can't be implemented as extensions. I'd like to expend more energy
on making sure there are good implementations and that the spec is
consistent, complete, and readable than on jamming in new features.

That said, I'm in favor of proposals that make the spec easier to
understand. There are two of these, "Remove SIGNALL" and
"IdP-supported Delegation." Everything else is either neutral or adds
complexity.

A summary of my thinking about the existing proposals:

* IdP-supported Delegation (reduces complexity)
  +1 because it makes the protocol easier to follow and easier for a
Relying Party to implement, and the cost is minimal

* Rename trust_root to realm (complexity neutral)
  -0 because it'll be annoying to have the same field with two
different names in the code

* Remove SIGNALL (reduces complexity)
  +1 because this proposal decreases complexity (maybe +2 since there
are security concerns also)

* Standard multi-value parameter mechanism (adds complexity)
  -1 in the authentication spec, +0 in some other document

* Request nonce and name (adds a trivial amount of complexity)
  -0 on request nonce (since you can already do that by adding it to
the return_to)
  +1 on name change *if* a request nonce is added, otherwise -0

* Authentication age (adds complexity)
  -1 in the core spec, +1 in an extension

* Bare response / bare request (adds complexity)
  -0.5 I'm not convinced that it's necessary (there are other ways to
do it that don't make the spec more complicated)

Josh