Summarizing Where We're At

[Dick Hardt]

On 17-Oct-06, at 10:30 AM, Josh Hoyt wrote:

> On 10/17/06, Dick Hardt <dick at sxip.com> wrote:
>> Josh, would you elaborate on the reasoning behind your votes so that
>> I (and others) understand?
>
> Sure. I'll try to be brief.

Thanks!

>
>> > On 10/15/06, Recordon, David <drecordon at verisign.com> wrote:
>> >> * Request Nonce and Name
>> > Take no action
>
> response_nonce is already in the spec [1]
>
> There is no other proposal to vote on, so no vote, no action

clarified, thanks

>
>> >> * Authentication Age
>> >>  - Re-proposed today adding clarity in motivation, general
>> >> consensus is
>> >> needed to add to specification.
>> >
>> > -1
>
> There is no reason for this to be in the core. I could make more
> arguments about it, but I'll stop there, unless there is consensus
> that it should go in the core.

Would you provide a reason to counter my justification:
	http://openid.net/pipermail/specs/2006-October/000433.html

Your vote is a -1, not a zero, so I would like to understand why.

>
>
>
>> >> * Remove setup_url
>> >>  - Little discussion and no general consensus to do so.  Rather  
>> seems
>> >> asking for feedback from checkid_immediate implementers on the
>> >> parameter
>> >> would be beneficial at this time.
>> >
>> > +1
>
> setup_url made the API for our libraries more complex. The relying
> party does not need it to know how to proceed when immediate mode
> fails.

Thanks.

>
>
>
>> >> * Consolidated Delegation Proposal
>> >>  - Very active discussion, the only proposal I'm willing to  
>> stall the
>> >> spec for.  Seems very important a strong conceptual model is
>> >> created at
>> >> this time.
>
> See the other 1000 messages about this topic.
>
>> > -0 on status quo (draft 10)
>
> The status quo works, but has some warts [2]
>
>> > +0 on single-identifier
>
> also has some warts (required IdP discovery, dependency on IdP support
> for portable identifiers),

would you clarify those two points

> but is less confusing than the status quo
>
>> > +1 on two-identifier
>
> two-identifier is explicit about what's going on without imposing any
> policy on the IdP. Easy to understand and specify. Minimal change from
> the current working system.

What policy is imposed on the IdP?

>
>
>
>> >> * Change Default session_type
>> >>  - Proposed, no discussion yet.
>> >
>> > Will address in separate message
>
> Mike Glover beat me to it [3]. I'd rather just make the session type a
> required parameter (no default)
>
>
>
>> >> * Bare Request
>> >>  - Proposed, no discussion yet.
>> >
>> > -0 (YAGNI)
>
> You Ain't Gonna Need It [4]

Well maybe YAGNI, but we have use cases that use it in prototype! :)