[OpenID] Simple Registration Extension 1.1 draft 1

[Jack]

Kevin Turner wrote:
> On Tue, 2007-09-11 at 14:51 +0100, Jack wrote:
>> ".sreg" part is going to depend on the namespace mapping that is
>> defined by the "openid.ns.something" parameter.  And so the part
>> called "openid.ns.sreg" _IS_ required, although it might actually
>> be "openid.ns.something" - the other parts cannot be evaluated
>> without the namespace declaration.
> 
> This is dependent on the version of OpenID you are using.  Version
> 1.x does not require openid.ns, version 2.0 requires it for all
> extensions. See 
> http://openid.net/specs/openid-authentication-2_0-12.html#extensions
> 
> This applies to your comments about the presence or absence of the 
> namespace field in the response message as well.

Ah - nice. So Sreg 1.1 can be used with either OpenID 1.x or OpenID 2.0,
even though namespaces aren't covered by 1.x.

I suppose that means that a Sreg 1.1 extension-handler that has to work
with OpenID1.x MUST use the literal namespace label "openid.sreg"?

I guess it's a significant disadvantage of spec fragmentation, that you
risk conflicts like this:

OpenID 2.0:
     "To associate keys and values in a message with an extension, the
      key MUST be associated with the Type URI."

SReg 1.1:
     "All of the following request fields are OPTIONAL, though at least
      one of "openid.sreg.required" or "openid.sreg.optional" MUST be
      specified in the request.
       openid.ns.sreg:
           "http://openid.net/extensions/sreg/1.1"
       [...]
> 
> This is true, but making a distinction between the two allows for the
>  provider to show a UI hint.

OK, that's the only purpose that I could see in it. However I have yet
to meet a OP that displays such a hint (or perhaps I just didn't notice it).
> 
>> Is there a requirement that the namespace label in the response
>> should have the same value as it had in the request? That is,
>> should an RP be prepared for the label to have changed?
> 
> That's really the only sane way to write an OpenID 2.0 message
> parser. The label is only meaningful in the context of that one
> message, and it's nothing more than an alias.
> 
Good. Now I'm wondering if I can think up a scenario that would result
in the OP having to switch labels between the request and the response,
because of a collision. That would have to result from extension data
being included in the response that wasn't asked-for in the request, I
suppose. And as far as I can see, that is explicitly permitted - "The
behavior in the case of missing required fields or extra, unrequested
fields is up to the Consumer." [Sreg1.1#response_format]

OK, thanks for clarifying.

-- 
Jack.