Summarizing Where We're At

[Dick Hardt]

On 17-Oct-06, at 3:16 PM, Recordon, David wrote:

> The nonce parameter has already been renamed to response_nonce (see
> draft 10) and I do not see the need for a request nonce within the
> protocol.  See prior discussion on that.
>
> There is nothing dictating it will be an extension forever.  I  
> don't see
> it being responsible adding it to the core specification at this point
> while questions of how to handle age around multiple factors of
> authentication, representing the type(s) of authentication used, or
> "authentication" on account creation (captcha, SMS, email, etc) are
> still rampant.

I don't recall seeing any significant discussion on those, and the RP  
can do captcha, SMS and email as they do today.
You can think of OpenID providing the equivalent of username/password  
-- which means the RP would like some to make a request as to wether  
the authn action is performed or not.

I can write this up as an extension, but then once people are using  
it as an extension and it is deployed, that is likely how it will be.

Given the extension mechanism, it is unlikely there will be  
significant changes to OpenID after this version.

> Two identifiers are far more verbose and clear, but there is also  
> plenty
> of discussion on this.

I think they are redundant, confusing and misleading. :)

>
> As I said back in September, I'm only tracking proposals listed on the
> wiki page.  :)
>
> --David
>
> -----Original Message-----
> From: Dick Hardt [mailto:dick at sxip.com]
> Sent: Tuesday, October 17, 2006 12:25 PM
> To: Recordon, David
> Cc: Josh Hoyt; specs at openid.net
> Subject: Re: Summarizing Where We're At
>
>
> On 16-Oct-06, at 3:24 PM, Recordon, David wrote:
>
>> And here are my votes:
>>
>> Request nonce and name
>>  * Take no action
>
> So you are saying to NOT rename the parameter?
>
> +1 rename nonce to response_nonce
> +1 to put request_nonce in an extension for RP identity related
> functionality
>
>> Authentication age
>>  * -1, write as an extension first
>
> Hmmm, that seems different then what you wrote earlier.
> If it is an extension, it will be an extension forever.
> It is optional, and is part of auth.
>
> I am +1 it is in the spec.
>
>>
>> Remove setup_url
>>  * 0 for removing, +1 for asking feedback from implementers
>>
>> Consolidated Delegation Proposal
>>  * -1 on status quo (draft 10)
>>  * 0  on single-identifier
>
> +1
>
>>  * +1 on two-identifier
>
> -1 -- two identifiers are redundant and confusing. 1.x spec only  
> had one
> identifier.
>
>>
>> Change default session type
>>  * +1
>
> 0
>
>>
>> Bare request
>>  * 0
>
> +1
>
> btw: I don't think we have all the issues here.
>
>