[OpenID] Question regarding the OpenID Information Cards 1.0

[Peter Williams]

> 11.2.  Verifying Discovered Information requires that:
> 
> "[...] the Relying Party MUST perform discovery on the Claimed
> Identifier in the response to make sure that the OP is authorized to
> make assertions about the Claimed Identifier."

[Peter Williams] 

Last week, from memory I wrote "There is a step 5. The RP must identify
the OP(s) associated with the Claimed_Identity, as published by the user
in his/her HTML/XRDS file." 

This was worried me ever since.

1. In the traditional flow, we do discovery on the user's "claimed
input", as normalized. This is an authority-to-speakfor control, done
pre assertion validation. Without authority established, don't even send
auth req.

2. In the token-based flow, the equivalent discovery control is on the
Claimed_Identity. This is the authority--speak-for control, done post
assertion validation. Without authority established, don't validate auth
resp.

We know the Claimed_Identity is allowed fragments etc, on the token
flow. The user's input was not, in the non-token flow. Yet they are
performing the same security control. Internal inconsistency: alarm
bells sounded.

To be consistent, one could normalize the Claimed_Identity as in the
non-token flow. But this worries me, too. In OpenId Auth 2.0, the
semantics of Claimed_Identity are complex. I know I don't fully
understand the (hardly discussed) authority model. I therefore worry
about normalizing the Cliamed_Identity, following redirects etc, before
applying the authority control.

As I've remarked a couple of times. The spec is excellent for
implementers; but it lacks models and rationales that allow one to
easily determine which mechanisms in the various states of the state
machine enforce which controls, under which triggers and conditions.