Wrapping Up Proposals

[Recordon, David]

I agree, though also think some things are worth addressing now.

* IdP-supported Delegation
	While it reduces complexity, it means that each IdP now has to
handle delegated identifiers as well.  As the point of delegation is to
use an identifier your IdP doesn't assert, for whatever reason, I have a
hard time having the IdP know what identifier you're using as it may
decide it doesn't like that.

* Rename trust_root to realm
	I think this adds a lot of clarity, and while it will mean code
needs to know of both for backwards compatibility, we need to make this
jump at some point.

Agreed with you on SIGNALL and multi-value parameters.

I agree with using return_to, though renamed openid.nonce to
openid.response_nonce in the spec to also add clarity.  I think the
extra 9 characters will be beneficial in the long run so we don't need
to rename it some other time.

Agreed on authentication age, should be an extension for the time being.

Don't have a strong opinion on bare response / request, but don't think
it should delay 2.0; so leave it out for now.

--David

-----Original Message-----
From: joshhoyt at gmail.com [mailto:joshhoyt at gmail.com] On Behalf Of Josh
Hoyt
Sent: Monday, October 02, 2006 5:35 PM
To: Recordon, David
Cc: specs at openid.net
Subject: Re: Wrapping Up Proposals

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