[OpenID] Claimed Identifiers and Query String Parameters

[Martin Atkins]

SitG Admin wrote:
> 
> As described in my first reply to Joe Tele, the idea is to look for (a 
> hash of) the typed-in ("claimed") ID *and* the Directed ("final") ID, 
> requiring a match on *both* of those strings to proceed. I designed mine 
> this way because I didn't understand what was going on with Directed 
> Identity well enough to be *certain* there weren't any risks in relying 
> on just the Directed identifier.
> 

One of the steps in verifying a positive assertion from an OP -- in the 
directed identity flow or otherwise -- is ensuring that the OP that 
provided the assertion is declared as a provider for the URL it is 
asserting for, using the same discovery steps that found the OP in the 
first step.

Most of the time you can optimise this by retaining some information at 
your end when you initiate the request so that you don't need to repeat 
discovery. For example, you can cache the discovery results for a given 
URL so that when you need to repeat discovery to process the positive 
assertion you don't need to make a further HTTP request. In the directed 
identity case though, you won't have yet done discovery on the final 
identifier so the right time to do this is when verifying the positive 
assertion.

If you verify that the final identifier declares the asserting OP as an 
allowed provider as required by the spec then there ought to be no more 
risk to it than the standard claimed identifier flow. Certainly I can't 
think of any advantage you gain by storing the OP identifier. If you 
want to "lock" an identifier to a given OP (which I don't think is a 
good idea anyway) it's probably better to use the OP *endpoint* URL as 
the key, since this is what the spec itself uses as the primary 
identifier for an OP.