Re: Summarizing Where We Are
Dick Hardt wrote: > On 5-Oct-06, at 4:41 PM, Josh Hoyt wrote: > >> On 10/5/06, Dick Hardt <[EMAIL PROTECTED]> wrote: >>> I think you missed my message arguing why it was important and that >>> being part of the return_to URL made it hard for the functionality to >>> be contained in the library >> I'm not sure I buy this reasoning, since our OpenID 1 libraries add a >> nonce to the return_to URL (which is not hard, since the library needs >> to add stuff to the return_to URL anyway) > > curious as to why the RP library needs to add stuff to the return_to > URL? Does it need to for a OpenID 2.0 call? > One example that springs to mind is that the original Perl OpenID library would, in the delegation case, put the user-supplied identifier in a return_to argument so that it could use that identifier when authentication succeeded. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Summarizing Where We Are
On 5-Oct-06, at 4:41 PM, Josh Hoyt wrote: > On 10/5/06, Dick Hardt <[EMAIL PROTECTED]> wrote: >> I think you missed my message arguing why it was important and that >> being part of the return_to URL made it hard for the functionality to >> be contained in the library > > I'm not sure I buy this reasoning, since our OpenID 1 libraries add a > nonce to the return_to URL (which is not hard, since the library needs > to add stuff to the return_to URL anyway) curious as to why the RP library needs to add stuff to the return_to URL? Does it need to for a OpenID 2.0 call? > > That being said, I think it's a quite reasonable parameter. :) > I just > think that this particular argument is bogus. It could be! ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Summarizing Where We Are
On 10/5/06, Dick Hardt <[EMAIL PROTECTED]> wrote: > I think you missed my message arguing why it was important and that > being part of the return_to URL made it hard for the functionality to > be contained in the library I'm not sure I buy this reasoning, since our OpenID 1 libraries add a nonce to the return_to URL (which is not hard, since the library needs to add stuff to the return_to URL anyway) That being said, I think it's a quite reasonable parameter. I just think that this particular argument is bogus. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Summarizing Where We Are
Yeah, I think I did. Was there another message I missed besides http://openid.net/pipermail/specs/2006-October/000200.html? --David -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Thursday, October 05, 2006 4:19 PM To: Recordon, David Cc: specs@openid.net Subject: Re: Summarizing Where We Are On 5-Oct-06, at 3:20 PM, Recordon, David wrote: > * Request nonce and name > Proposal as a whole has been rejected. Request nonce can be > contained within the "return_to" parameter as the IdP redirects the > user-agent back to it upon completion of the request. Will post vote > thread posted to rename openid.nonce to openid.response_nonce. I think you missed my message arguing why it was important and that being part of the return_to URL made it hard for the functionality to be contained in the library ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Summarizing Where We Are
On 5-Oct-06, at 3:20 PM, Recordon, David wrote: > * Request nonce and name > Proposal as a whole has been rejected. Request nonce can be > contained within the "return_to" parameter as the IdP redirects the > user-agent back to it upon completion of the request. Will post vote > thread posted to rename openid.nonce to openid.response_nonce. I think you missed my message arguing why it was important and that being part of the return_to URL made it hard for the functionality to be contained in the library ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Summarizing Where We Are
Trying to catch up on all the discussion in the past 36 hours. Been great to read through it all, really shows the interest and excitement that we all have in OpenID. I do however want to rope everyone back in a bit so we can focus on what is going to be a reality within the Auth 2.0 spec. I would like to have draft 10 published by next Friday, that gives us all slightly over a week to finish discussion and make the changes to the spec itself. The goal is that draft 10 then becomes used for implementations and only changes in draft 11 are from problems found via implementations and general cleanup. For any proposal that hasn't been accepted, I will post a call for a formal vote the morning of Tuesday the 10th so that the votes will end Friday morning. Please keep in mind that 2.0 will not be the last version of OpenID Authentication, thus we should not force proposals in if more discussion is needed. Here is my current understanding of the status for each proposal: * IdP-supported Delegation & Separate Public Identifier from IdP Identifier Still being highly discussed with an additional proposal made by Mart and one by Chris Drake. * Rename trust_root to realm Accepted (4 +1, 1 0, 0 -1) * Remove SIGNALL Accepted (6 +1, 0 0, 0 -1) * Standard multivalue parameter mechanism Current opinion (1 +1, 0 0, 2 -1). General consensus is that this should not be a requirement of the specification itself, rather as part of each extension where this becomes needed. Differing extensions may have differing requirements for delimiters. * Request nonce and name Proposal as a whole has been rejected. Request nonce can be contained within the "return_to" parameter as the IdP redirects the user-agent back to it upon completion of the request. Will post vote thread posted to rename openid.nonce to openid.response_nonce. * Authentication age Still being highly discussed. * bare response / bare request Still being discussed Cool? Cool! --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
