Re: Backporting the 2.0 extension mechanism to 1.1

2008-08-12 Thread Martin Atkins
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


Email Address to URL Transformation

2008-08-12 Thread Arshad Khan
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: Email Address to URL Transformation

2008-08-12 Thread sakimura
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


Re: Backporting the 2.0 extension mechanism to 1.1

2008-08-12 Thread sakimura
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

2008-08-12 Thread James Henstridge
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