Re: Backporting the 2.0 extension mechanism to 1.1

2008-08-13 Thread Nat Sakimura
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

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


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


Backporting the 2.0 extension mechanism to 1.1

2008-08-11 Thread Martin Atkins

I notice that, like sreg, the pape extension is supporting 1.1 by simply 
hard-coding the pape prefix on its arguments.

This approach is troublesome for the Net::OpenID::Consumer perl library 
because it deals only in extension URIs, and supports sreg in 1.1 as a 
special case. In order to preserve the abstraction the library would 
need to be altered each time an extension adds a new hard-coded prefix 
in this way, which is not ideal.

Therefore I'd like to propose that for PAPE and all future 
specifications the 2.0 extension mechanism simply be allowed in 1.1. I 
don't think it needs any modification in order to work for 1.1, except 
that for legacy reasons SREG should continue to have the sreg prefix 
reserved when in 1.1 mode.




___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


Re: Backporting the 2.0 extension mechanism to 1.1

2008-08-11 Thread Johnny Bufu


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

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

2008-08-11 Thread Nat Sakimura
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