OPs to advertise support for OpenID extensions via the extension's type URI

[Andrew Arnott]

Hi folks,
Breno just pointed out to me that the UI extension's draft spec, Discovery
section <http://wiki.openid.net/f/openid_ui_extension_draft01.html#anchor6>
calls
out two type URIs that should appear in an OpenID identifier's XRDS
document.  But neither of these type URIs is the type URI of the extension
itself.

DotNetOpenId and DotNetOpenAuth both take for granted that an extension's
primary type URI (the one that appears at the value of the openid.ns.*
someext* parameter) is expected to appear in an XRDS document if the OP
supports that extension.  Maybe that wasn't a spec'd out behavior for OpenID
extensions, but it seems to hold true for the OPs I tested at the time.

While it's neat to see the UI extension include a specific Discovery section
that allows OPs to declare their support for the different parts of the
extension, there's no mention of declaring the extension itself.  As a
result, RPs (at least the ones based on DNOI/DNOA) may not think that an OP
supports the UI extension when in fact it does.

So I'm requesting two things:

   1. Can we get the UI extension DRAFT spec updated to include that the
   http://specs.openid.net/extensions/ui/1.0 URI be included in the XRDS
   document?
   2. Can we standardize on the idea that an extension's type URI should be
   in an XRDS document if the OP supports it so that RPs can easily scan for
   all supported extensions? (this would be in addition to any additional type
   URIs the extension wants to define and advertise)

What do you all think?

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20090722/39bd4e16/attachment.htm>