Re: Extensions key prefix
Rowan Kerr wrote: [snip] > i.e. While the spec for Attribute Exchange uses "openid.ax" for its > message keys, and Simple Reg 1.1 uses "openid.sreg", in reality the > keys received in a message are determined by whatever comes after the > key openid.ns.* where the value is the URI of the extension putting > data into those keys. > > So, openid.ns.ax = http://openid.net/srv/ax/1.0 implies > openid.ax.required. > > But it could just as easily be openid.ns.foo = http://openid.net/srv/ > ax/1.0 > in which case, your sreg values would be in keys named openid.foo.* > I was aware of this previously, but now that you've spelled it out a thought has occured to me... Most frameworks model the query string arguments as an associative array, so it's useful to know what key you're expecting ahead of time. With the above naming scheme, it seems to me that you'd have to search the entire query argument map for a key,value pair where the value is the URL you're looking for and the key matches /^openid.ns.(\w+)$/. This seems sub-optimal, but I must admit I don't know what else to suggest. While putting the URL in the "key" and the prefix in the value would not be invalid, it'd be troublesome in PHP where for historical reasons it mangles anything that wouldn't be a valid variable name. Or am I missing something? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Extensions key prefix
On 13-Mar-07, at 6:23 PM, Drummond Reed wrote: > I hadn't gleaned that out of earlier readings of the spec, > and I think it should be emphasized (in fact I'd recommend the > analogy to > xmlns prefixes. Making the link between the openid.ns.* and XML namespaces would be enough to clarify it in my mind. But it should clearly spell out the usage as well in case people reading and implementing the spec are not entirely familiar with how XML namespaces work. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Extensions key prefix
On 13-Mar-07, at 6:23 PM, Drummond Reed wrote: > If I understand you correctly here, what you are saying is that > openid.ns.* > prefixes work almost identically to XML namespace (xmlns) prefixes, > i.e.: > > * the prefix is never globally defined by dynamically defined on a > per-instance basis > * thus you don't know what the prefix is in a specific OpenID > message until > you parse the message. > > Do I have that right? That's exactly it. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Extensions key prefix
On 13-Mar-07, at 6:23 PM, Drummond Reed wrote: > Rowan, > > If I understand you correctly here, what you are saying is that > openid.ns.* > prefixes work almost identically to XML namespace (xmlns) prefixes, > i.e.: that is where the idea came from :-) > > * the prefix is never globally defined by dynamically defined on a > per-instance basis ... never globally defined *but* is dynamically defined ... > * thus you don't know what the prefix is in a specific OpenID > message until > you parse the message. correct -- and good point to call it out as clearly it is not obvious to people -- thanks! -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Extensions key prefix
Rowan, If I understand you correctly here, what you are saying is that openid.ns.* prefixes work almost identically to XML namespace (xmlns) prefixes, i.e.: * the prefix is never globally defined by dynamically defined on a per-instance basis * thus you don't know what the prefix is in a specific OpenID message until you parse the message. Do I have that right? If so, I agree, I hadn't gleaned that out of earlier readings of the spec, and I think it should be emphasized (in fact I'd recommend the analogy to xmlns prefixes. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rowan Kerr Sent: Tuesday, March 13, 2007 5:05 PM To: OpenID specs list Subject: Extensions key prefix In all my time spent reading and implementing the OpenID Authn 2 spec, this particular detail escaped me. Johnny Bufu pointed it out to me the other day while we were going through some Attribute Exchange tests. http://openid.net/specs/openid-authentication-2_0-11.html#extensions "To associate keys with a Type URI, establish an alias by adding a key prefixed with "openid.ns." and ending with the alias text whose value is the Type URI." I never picked up on the fact that these aliases can be dynamic on a per-server or actually per-messsage basis, and assumed the key prefixes listed in the extension specs were what one could expect to see in a message. This affects all proposed extensions to OpenID 2.0... i.e. While the spec for Attribute Exchange uses "openid.ax" for its message keys, and Simple Reg 1.1 uses "openid.sreg", in reality the keys received in a message are determined by whatever comes after the key openid.ns.* where the value is the URI of the extension putting data into those keys. So, openid.ns.ax = http://openid.net/srv/ax/1.0 implies openid.ax.required. But it could just as easily be openid.ns.foo = http://openid.net/srv/ ax/1.0 in which case, your sreg values would be in keys named openid.foo.* Is this clear to everyone else? It makes sense to me now, but I think it should be made more clear in the main spec, and perhaps the extension specs could move away from hardcoding the openid.ns.* and use an obvious placeholder string. -Rowan ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Extensions key prefix
In all my time spent reading and implementing the OpenID Authn 2 spec, this particular detail escaped me. Johnny Bufu pointed it out to me the other day while we were going through some Attribute Exchange tests. http://openid.net/specs/openid-authentication-2_0-11.html#extensions "To associate keys with a Type URI, establish an alias by adding a key prefixed with "openid.ns." and ending with the alias text whose value is the Type URI." I never picked up on the fact that these aliases can be dynamic on a per-server or actually per-messsage basis, and assumed the key prefixes listed in the extension specs were what one could expect to see in a message. This affects all proposed extensions to OpenID 2.0... i.e. While the spec for Attribute Exchange uses "openid.ax" for its message keys, and Simple Reg 1.1 uses "openid.sreg", in reality the keys received in a message are determined by whatever comes after the key openid.ns.* where the value is the URI of the extension putting data into those keys. So, openid.ns.ax = http://openid.net/srv/ax/1.0 implies openid.ax.required. But it could just as easily be openid.ns.foo = http://openid.net/srv/ ax/1.0 in which case, your sreg values would be in keys named openid.foo.* Is this clear to everyone else? It makes sense to me now, but I think it should be made more clear in the main spec, and perhaps the extension specs could move away from hardcoding the openid.ns.* and use an obvious placeholder string. -Rowan ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
