[OpenID] Question regarding the OpenID Information Cards 1.0

[Johnny Bufu]

On 4-Sep-07, at 1:32 PM, Peter Williams wrote:
> 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).

Why just "assume"? You have just discovered (barring any security  
attacks) that it is so.

> 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.

You should also call discovery in two different points:
- for stateless RP operation (n/a if your RP can keep state)
- when accepting unsolicited auth responses or with different  
identifiers than the requests (e.g. the OpenID token use case, but  
not only)

> 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)?

No, the discovery process is the same regardless of where / when it  
is called, and normalization is part of the discovery (normalization  
yields the claimed_id for URLs). So you can use the same X routine.

If the information discovered from the claimed_id in the assertion  
has a different claimed_id, then the verification will fail. The  
table in section 11.2 contains the left hand (discovered info) and  
right hand (assertion data) operands that need to be compared.

You do have to strip the fragment from the right-hand claimed_id  
operand though (as required by the first paragraph in 11.2).

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

No; the whole claimed_id URL consitutes the OpenID identifier.

drupal.org/?u=123 is a different user / identifier than drupal.org/? 
u=456.

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

Why and from whose point of view? What kind of trust are you  
referring to?


> 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.

If that is so, it will be revealed by :

a) discovered information verification (the added querystring values  
won't show up in the discovered info, so the discovered-info- 
claimed_id won't match the assertion-claimed_id).

	and / or

b) the signature verification (performed against the authoritative OP  
discovered from the claimed_id in the assertion)


Alterations to the claimed_id will fail on a) (and not even reach b),  
while modification to other signed parts of the message will fail b).


> 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?

 From the OpenID point of view, the cardspace / selector is not  
assumed to be trusted; the OpenID verification process is.


Johnny