Hi David, What is the rush for? There's a lot of unhappy people here due to missing protocol elements.
I for one believe the lack of privacy considerations is an entire OpenID "killer". Is there a reason why you've omitted my IdP-initiated login proposal from your short list (also known as "bookmark login url discovery")? If you're not convinced of the importance of privacy - read your own IdP home page: http://pip.verisignlabs.com/ " Verify your identity without compromising your privacy with PIP, the personal identity management system from VeriSign. " Verisign chose Privacy as *the* most important and critical feature that their IdP should support - does your PIP service plan to *use* OpenID, and if so, how do you propose to handle privacy problems (eg: RP's collaborating about users behind their backs) ? Imposing an arbitrary time limit will result in an incomplete spec. Kind Regards, Chris Drake Monday, October 16, 2006, 5:28:52 AM, you wrote: RD> So previously I had set the goal of the final draft coming out last RD> Friday, though we've missed that. I'm resetting this bar to Wednesday RD> which means we need to wrap up discussion on proposals where there is RD> general consensus as well as accept that some proposals will not make it RD> into this version. For all proposals, unless there is general consensus RD> they should be included by Tuesday evening they will not be included. RD> * Request Nonce and Name RD> - Has been partially implemented, openid.nonce -> RD> openid.response_nonce, no agreement on the need of a request nonce RD> specifically, rather discussion has evolved into allowing a RP to pass RD> "appdata" like in Yahoo's BBAuth. No formal proposal on the table yet, RD> thus will not be included in this version. RD> * Authentication Age RD> - Re-proposed today adding clarity in motivation, general consensus is RD> needed to add to specification. RD> * Remove setup_url RD> - Little discussion and no general consensus to do so. Rather seems RD> asking for feedback from checkid_immediate implementers on the parameter RD> would be beneficial at this time. RD> * Consolidated Delegation Proposal RD> - Very active discussion, the only proposal I'm willing to stall the RD> spec for. Seems very important a strong conceptual model is created at RD> this time. RD> * Change Default session_type RD> - Proposed, no discussion yet. RD> * Bare Request RD> - Proposed, no discussion yet. RD> I also feel strongly that no new proposals, except to update existing RD> ones, should be considered for inclusion in this version. RD> --David RD> _______________________________________________ RD> specs mailing list RD> firstname.lastname@example.org RD> http://openid.net/mailman/listinfo/specs _______________________________________________ specs mailing list email@example.com http://openid.net/mailman/listinfo/specs