[OpenID] When TWO xrds docs are published at ONE url...

[Drummond Reed]

This scenario is not valid. URL-based XRDS discovery in section 6 of
http://docs.oasis-open.org/xri/xri-resolution/2.0/specs/cd03/xri-resolution-
V2.0-cd-03.html is unambiguous RE precedence, so only one XRDS document is
valid. See the precedence rules in sections 6.2 and 6.3

 

=Drummond 

 

  _____  

From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
Behalf Of Andrew Arnott
Sent: Monday, June 23, 2008 10:22 PM
To: OpenID List
Subject: [OpenID] When TWO xrds docs are published at ONE url...

 

I ran across an OpenId URL endpoint that someone had, that published one
XRDS document via its HTTP headers, and a different XRDS doc via its HTML
META tags.  One doc had the RP discovery information (return_to url), and
the other doc had the openid:delegate/LocalId tags in it that delegated
authentication to myopenid.com.  I believe that only one doc should be
published, nevertheless, I'm curious about how to best deal with the problem
since it exists out there...

I noticed that DotNetOpenId (which I develop) reads the first XRDS doc
reference it notices and only that doc.  The Janrain python library at
openidenabled.com on the other hand appeared to have either read both docs,
or at least successfully found the right doc to get the endpoint information
because it successfully authenicated the user, whereas dotnetopenid failed
to find the endpoint info.

So to wrap up, my questions are these: 
1. How valid is a two separate XRDS doc scenario?
2. What should an RP do to make sure it works in this case for users?
Anything?  DotnetOpenId sends an Accept-Content HTTP header, and sometimes
gets one of the two XRDS docs back immediately instead of the HTML, so we'd
have to make TWO requests just to test for the existence of a reference to a
second doc if we wanted to rigorously read both.

Suggestions?  ideas?

--
Andrew Arnott 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20080624/2ad7e3ce/attachment-0002.htm>