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