[OpenID] Question regarding the OpenID Information Cards 1.0

[Johnny Bufu]

On 4-Sep-07, at 7:46 AM, Peter Williams wrote:

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

I don't really see any issues. Please see my comments below.

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

Without the authority being determined (== discovered), there's no  
endpoint to send the auth req to.

If the OP replies with a different claimed_identifier, or just issues  
an unsolicited response, the RP is required to validate the assertion  
in the normal flow, and part of it is validating the discovered  
information.

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

Not *post* assertion validation : discovered information is *part of*  
assertion validation. The whole assertion is not validated until all  
four validation steps are completed.

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

I think it would be a lot easier to follow if you have a example  
where the validation doesn't work correctly, in either flow.  
Personally I don't see any issues.

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


Johnny