Re: Backporting the 2.0 extension mechanism to 1.1
Since PAPE needs more integrity in the message (otherwise, the whole point of PAPE is lost), it would be ok to leave it just to OpenID 2.0 and make it an incentive to move to OpenID 2.0, IMHO. =nat Johnny Bufu wrote: On 11/08/08 10:35 AM, Martin Atkins wrote: In that referenced section it says: For the purposes of this document *and when constructing OpenID 1.1 messages*, the extension namespace alias SHALL be pape. (emphasis mine) I understand that to mean that when making a 1.1 request the alias must be pape. You're right - my brain must have left out the portion you emphasized, since it didn't use to be there. I thought PAPE was not meant to be compatible with 1.1, exactly for the reasons you outlined in the initial message. Not sure what the best approach would be here: specify how PAPE could be used with OpenID 1.1, or leave it as an incentive to upgrade to 2.0. Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Backporting the 2.0 extension mechanism to 1.1
Nat Sakimura wrote: Actially, that interpretation is not right. In draft 3, we have made it clear. Draft 3 now seems to say: For the purposes of this document and when constructing OpenID 1.1 and 2.0 messages, the extension namespace alias SHALL be pape. Which now seems to require that pape must always be the namespace alias, in both 1.1 and 2.0. I don't understand what the intention of this sentence is if this is not a correct interpretation. However, my original message was not really a comment on the PAPE spec so much as a comment on the general lack of an extensibility mechanism in OpenID 1.1. The PAPE spec (the sentence I quoted above notwithstanding) currently seems to assume that the 2.0 namespace mechanism is available in 1.1, but as far as I'm aware there has never been a published specification allowing this. (please correct me if I'm wrong.) The Net::OpenID::Consumer perl library as it currently stands will not support PAPE in 1.1-mode messages since the openid.ns.alias mechanism is only used in 2.0 mode. I'd like to change this to use the 2.0 scheme in 1.1 (with a special case for sreg) but I'm only comfortable doing that if there's a specification (or errata) that explicitly allows it. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Backporting the 2.0 extension mechanism to 1.1
The preceding sentence goes: The actual extension namespace alias should be determined on a per-message basis by the party composing the messages, in such a manner as to avoid conflicts between multiple extensions. Thus the intent of the For the purposes of this document and when constructing OpenID 1.1 and 2.0 messages, the extension namespace alias SHALL be pape. is that, pape in this document and the actual messages should be treated as a placeholder, which should be replaced message by message. Having said that, I agree that this is very misleading. I read it exactly as you did in the first path, so did Mike Jones. It was only after I have read the spec in full, that if it were not placeholder, it would not make sense as a coherent spec. I suppose we should fix the sentence as well. (Note: in draft 3, we have replaced all appearance of pape with pape to signify that it is a template. As to the backporting: if we do backport, it would not be 1.1 anymore, I guess. Perhaps you can just support 2.0 and that will accelerate the shift to version 2.0. =nat On 8/13/08, Martin Atkins [EMAIL PROTECTED] wrote: Nat Sakimura wrote: Actially, that interpretation is not right. In draft 3, we have made it clear. Draft 3 now seems to say: For the purposes of this document and when constructing OpenID 1.1 and 2.0 messages, the extension namespace alias SHALL be pape. Which now seems to require that pape must always be the namespace alias, in both 1.1 and 2.0. I don't understand what the intention of this sentence is if this is not a correct interpretation. However, my original message was not really a comment on the PAPE spec so much as a comment on the general lack of an extensibility mechanism in OpenID 1.1. The PAPE spec (the sentence I quoted above notwithstanding) currently seems to assume that the 2.0 namespace mechanism is available in 1.1, but as far as I'm aware there has never been a published specification allowing this. (please correct me if I'm wrong.) The Net::OpenID::Consumer perl library as it currently stands will not support PAPE in 1.1-mode messages since the openid.ns.alias mechanism is only used in 2.0 mode. I'd like to change this to use the 2.0 scheme in 1.1 (with a special case for sreg) but I'm only comfortable doing that if there's a specification (or errata) that explicitly allows it. -- Nat Sakimura (=nat) http://www.sakimura.org/en/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Backporting the 2.0 extension mechanism to 1.1
On Wed, Aug 13, 2008 at 3:56 AM, Martin Atkins [EMAIL PROTECTED] wrote: The Net::OpenID::Consumer perl library as it currently stands will not support PAPE in 1.1-mode messages since the openid.ns.alias mechanism is only used in 2.0 mode. I'd like to change this to use the 2.0 scheme in 1.1 (with a special case for sreg) but I'm only comfortable doing that if there's a specification (or errata) that explicitly allows it. Perhaps you could do something similar to the python-openid library? If you are writing support for a new extension, you can use the registerNamespaceAlias(uri, tag) function from the openid.message module. When parsing OpenID 1.x messages (which can be determined by checking for the absence of openid.ns), it uses these namespace aliases to map the prefixes to URIs. Outside of the message parsing code, you can work purely in terms of namespace URIs, which limits the amount of code that needs to know about 1.x vs. 2.0. James. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Backporting the 2.0 extension mechanism to 1.1
On 11/08/08 12:49 AM, Martin Atkins wrote: I notice that, like sreg, the pape extension is supporting 1.1 by simply hard-coding the pape prefix on its arguments. Where/how? To my knowledge the opposite is true, per the last paragraph here: http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-02.html#anchor3 Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Backporting the 2.0 extension mechanism to 1.1
Johnny Bufu wrote: On 11/08/08 12:49 AM, Martin Atkins wrote: I notice that, like sreg, the pape extension is supporting 1.1 by simply hard-coding the pape prefix on its arguments. Where/how? To my knowledge the opposite is true, per the last paragraph here: http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-02.html#anchor3 In that referenced section it says: For the purposes of this document *and when constructing OpenID 1.1 messages*, the extension namespace alias SHALL be pape. (emphasis mine) I understand that to mean that when making a 1.1 request the alias must be pape. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Backporting the 2.0 extension mechanism to 1.1
Actially, that interpretation is not right. In draft 3, we have made it clear. [EMAIL PROTECTED] On 2008/08/12, at 2:35, Martin Atkins [EMAIL PROTECTED] wrote: Johnny Bufu wrote: On 11/08/08 12:49 AM, Martin Atkins wrote: I notice that, like sreg, the pape extension is supporting 1.1 by simply hard-coding the pape prefix on its arguments. Where/how? To my knowledge the opposite is true, per the last paragraph here: http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-02.html#anchor3 In that referenced section it says: For the purposes of this document *and when constructing OpenID 1.1 messages*, the extension namespace alias SHALL be pape. (emphasis mine) I understand that to mean that when making a 1.1 request the alias must be pape. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
