[OpenID] is it true?

Wed Aug 26 17:53:52 UTC 2009

There are two issues.

1.       The spec does not obviously say that the OP needs to determine the "validity" of the request parameters (particularly for the XRI.XRD.cid and XRI.XRD.SEP.LocalID case). And, Andrew picked up my point straightaway: that conformance does not require an OP to "validate" the request parameters before responding.

But, im pretty sure that as "value-add," certain OPs are in fact doing that, and it seems to be based on the OP using the XRI "canonical-id validity" process -doing  XRI resolution (not "discovery" formally) on the inbound cid. Those are OPs are TRUSTING the XRI apparatus, to gauge the trustworthiness of authorities.

 Since this not a standardized handling requirement, I believe that its appropriate that other OPs might use equally valid but distinct validity tests. For example googles test is, apparently: if certain parameter forms are present, just refuse service.  A second example would be when the OP opts to use the trusted resolution mode of XRI resolution, in which it tests the signed XRDs as the basis for its validity model. The advantage here is that those XRD's served by an XRI server whose canonical-IDs are https URI (per the spec), can now ALSO be validated (because the signature process is more generalize than validity logics based on testing that (provider+localid = cid) , as one walks the tree of name servers.

2.       As the UI of the OP does not know which synonym the user typed at the RP (it only knows the i-number, typically), it cannot even show the user the list of synonyms for that i-number. The RP and the OP may not infact even be using the same XRI servers (the RP may be using a walled garden install). The user and RP may together be using synonyms that are not visible/resolvable by the typical OP being intentionally private from that OP - yet which are tied to the public i-number server hierarchy. This I feel is a good feature of openid, as it sets the line - beyond which the OP is not allowed to go spidering/correlating resources and identities (because this is actively prevented by the "better" class of RP, by operational design).

From: openid-general-bounces at lists.openid.net [mailto:openid-general-bounces at lists.openid.net] On Behalf Of John Bradley
Sent: Wednesday, August 26, 2009 6:14 AM
To: openid-general at lists.openid.net
Subject: [OpenID] is it true?

Yes,

The OP receives the cannonicalID from the XRDS as the openid.claimed_id and the LocalID as the openid.identity.  The user input is not passed.

This also happens with URL identifiers and delegation if there are http redirects involved.

I have argued in the past that the two fields we have in openID 2.0 are problematic for identifiers other than URL and even for them not always sufficient.

Don't quite know where you are going with this,  but it is a known issue.

John B.
On 26-Aug-09, at 12:43 AM, openid-general-request at lists.openid.net<mailto:openid-general-request at lists.openid.net> wrote:

Date: Tue, 25 Aug 2009 21:10:00 -0700
From: Peter Williams <pwilliams at rapattoni.com<mailto:pwilliams at rapattoni.com>>
Subject: [OpenID] is it true?
To: "openid-general at lists.openid.net<mailto:openid-general at lists.openid.net>"
    <openid-general at lists.openid.net<mailto:openid-general at lists.openid.net>>
Message-ID:
    <BFBC0F17A99938458360C863B716FE463DCDF238FD at simmbox01.rapnt.com<mailto:BFBC0F17A99938458360C863B716FE463DCDF238FD at simmbox01.rapnt.com>>
Content-Type: text/plain; charset="us-ascii"

User types "@blog*lockbox" at RP

Discovery determines that XRD.canonicalid is !1234, and the XRD.SEP has local-id=homepw.myopenid.com

This form of SEP implies that the user desires openid2-style openid-delegation

On receiving a request in which cid=!1234 and identifier=homepw.myopenid.com, the OP ONLY responds IF it does a discovery on !1234, validates that cid-verification=true (and sees that there exists SEP.local-id == request.openid.identity).

Is it true that the OP does NOT know that the user typed @blog*lockbox at the RP?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090826/652550eb/attachment.htm>