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. 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
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 "" 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. 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: Email Address to URL Transformation
Formal answer is "no". I think Vidoop will eventually propose to form a working group on this eventually, but that is only my guess. =nat On 8/13/08, Arshad Khan <[EMAIL PROTECTED]> wrote: > Does OpenID 2.0 support 'Email Address to URL Transformation (EAUT)? > > > > There is some info on this page of what EAUT is: > > > > http://blog.vidoop.com/archives/139 > > > > Has Vidoop developed this outside OpenID 2.0 framework? > > > > Thanks. > > > > Arshad > > > > > > > > -- Nat Sakimura (=nat) http://www.sakimura.org/en/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Email Address to URL Transformation
Does OpenID 2.0 support 'Email Address to URL Transformation (EAUT)? There is some info on this page of what EAUT is: http://blog.vidoop.com/archives/139 Has Vidoop developed this outside OpenID 2.0 framework? Thanks. Arshad ___ 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. 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
