[OpenID] Question regarding the OpenID Information Cards 1.0

[Peter Williams]

> > To be consistent, one could normalize the Claimed_Identity as in the
> > non-token flow.
> 
> Normalization is only applied to the user's input. The claimed_id is
> already in the normalized form. If it is not, the validation will
fail.

[Peter Williams] 

I have a discovery routine today - X. The calling program provides input
of an identity URL, e.g. peter.verisign.com/#me. The routine does
normalization, INCLUDING the act of removing all such silly fragments
and separators, and sticks http:// on the front. (e.g.
http://peter.verisign.com/). It pings an HTML/XRDS file at this latter
URL, following redirects including https redirects. It learns one or
more OP URLs by parsing the metadata, if any. Those discovered URLs are
the location of OPs AND - to Pedro's point - we are ASSUMING THEY ARE
part of the means of the relying party becoming secure in the knowledge
that each of those OPs do indeed "speak for" the identity URL (and the
human behind it).

I have now two places where my code calls X.

(1) When a user visit the blogsite, the user types in
peter.verisign.com/#me in the OpenID form field. X is called. Life
continues much as in the JanRain C# sample code for OpenID Auth 1.x

(2) a user visits a website and an infocard selection sequences occurs.
Later on, a Claimed_ID "https://verisign.com/#me?hisname=peter" is sent
to my RP site on the same browser session as that used to initiate card
selection. It is currently subject to X, __during___ validation by the
RP.

Now...in case (2) Claimed_ID from the unvalidated-assertion is already
"normalized" you say, even though I have yet to complete validation.
Though I am merely in the "midst of" validating it, I SHOULD assume it's
normalized. I SHALL take it "as-is" and ping the site at that URL 

Does this mean I need a new routine Y (a subclass of X)? 

Y shall differ from X in that a Claimed_ID of value
https://verisign.com/#peter SHALL now be given to the HTTP library as is
(without me doing any fragment/separator/querystring stripping)? 

That is: (1) strips (2) does not. 

We can of course assume HTTP1.1 client compliance will in any case strip
silly #fragments in the case of (2). 

However, any query strings (if any on any on the as yet unvalidated
assertion, from an unknown party) will be communicated however. E.g.
Claimed_ID = https://verisign.com/?hisname=peter&hissocial=4123123124

----------

For either X or Y, I should be doing the following:-

I should set the HTTP library to follow redirects (upto say 12). In the
case of Y only, I shall release any querystring values on the Claimed_ID
from the unvalidated assertion to all those redirected sites -- as any
intermediating proxies shall determine

If Claimed_ID or any of those redirects are https URLs, I SHALL
AUTOMATICALLY follow them, and I shall issue OCSP requests to check the
server chain. I shall require the https library to check cert CN
consistency with the domainname, doing a DNS ping. I shall raise a
OpenID Assertion- validation exception if the redirects fail to get to a
200, cert sigs fail, cert chains fail to root in my rootkey MIB, OCSP
fails or cert is marked invalid/suspended, DNS fails, the https CN
controls fail, or SSL record layer raises an integrity exception.

--------------

Should we at least not have the RP strip any querystring? 

The party giving me this value at the moment is entirely untrusted
surely

The actual communicant is actually the cardspace browser activeX
control, which just removed the RSTR signatures and the openID token
wrapper provided by the STS, and sent me the Claimed_ID as a KV form
blob. For all I know, the code doing that removal also just altered the
assertion the STS originally created, adding querystring values.

Even if you argue the OpenID token handling code in the cardspace
handlers is trusted by the browser/cardspace SEFs, that is not something
that I can test as the RP, is it? 

Just being cautious.