Auth 2.0 Extensions: Namespace Prefixes

Granqvist, Hans hgranqvist at verisign.com
Tue Jun 5 15:53:59 UTC 2007


But it seems superflous: Since you cannot depend on args to
be ordered[1], you'll still need to iterate and match prefix
to values.

Also, any change adds complexity: You'll need to specify 
semantics to what happens if the list of extensions is
not there, or if it is incorrect, or if you use extensions
without declared namespaces, etc.

But if it still is needed, I'd propose, since the list of 
extensions is meta info, it should itself be an extension. 

     openid.ns.ext=some:fixed:uri
     openid.ext.namespaces=ns1,ns2,ns3
     openid.ns1.foo=...
     openid.ns1.bar=...
     openid.ns2.foo=...

This makes processing cleaner and it also makes it possible 
for future specification of extensional behavior (sounds 
very Sartre ;)

     openid.ext.policy=...
     openid.ext.foo=...


-Hans

[1] I'm looking at you HttpServletRequest.getParameterMap()

-----Original Message-----
From: specs-bounces at openid.net on behalf of Recordon, David
Sent: Tue 6/5/2007 8:00 AM
To: Martin Atkins; specs at openid.net
Subject: RE: Auth 2.0 Extensions: Namespace Prefixes
 
Since it seems no one has replied yet, I'd agree that this would make
implementations easier.  Iterating via a regular expression seems ugly
and hard to do (well except in Perl). :-\

--David

-----Original Message-----
From: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On
Behalf Of Martin Atkins
Sent: Monday, April 30, 2007 12:48 PM
To: specs at openid.net
Subject: Auth 2.0 Extensions: Namespace Prefixes


As currently defined, an extension has a global namespace URI as well as

a request-local alias/prefix. For an extension with the namespace 
http://example.com/blah that has a field "foo", the following fields are

to be sent:

     openid.ns.blah=http://example.com/blah
     openid.blah.foo=bar

It seems to me that the only way to discover the extension namespaces 
used in a particular message is to iterate over all keys looking for 
openid.ns.(\w+) and then see if the value matches.

This seems ugly since usually webapps deal with such arguments as a 
dictionary structure, and use dictionary dicipline while interrogating 
the values.

If we added an extra field:
     openid.extensions=blah,sreg,ax

then the extensions used in a message would be accessible by splitting 
that field on its commas and then accessing openid.ns.whatever for each
one.

It's still not ideal, of course; it'd be better if the full namespace 
URI were included in the "key" part of a (key,value) pair, but many 
frameworks[1] can't deal with wacky punctuation characters in the key.




[1] I'm looking at you, PHP.

_______________________________________________
specs mailing list
specs at openid.net
http://openid.net/mailman/listinfo/specs
_______________________________________________
specs mailing list
specs at openid.net
http://openid.net/mailman/listinfo/specs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20070605/9e9a6888/attachment-0002.htm>


More information about the specs mailing list