Just a suggestion which may be impractical due to URL size limit:
Instead of requiring a boolean in the response, how about adding an:
optional, general purpose, comma separated list of identifiers
with support for custom and maybe signed identifiers as well.
For example:
openid.auth_type:nophish, oob, grade5!JVNJAZFXJMF5N===
'nophish'-aware RP can just search for 'nophish'.
Best,
- Don Park
On Feb 1, 2007, at 7:56 PM, Recordon, David wrote:
> I think we all agree that talking about the method used is far more
> useful, though with this proposal we're really trying to balance it
> with
> simplicity in the authentication protocol itself. Maybe it is
> better to
> phrase the discussion around if the user provided a secret
> (password) to
> the OP or not to authenticate versus talking about phishing
> directly.?.
>
> I'd hope that this parameter in the auth spec really helps bring the
> discussion around to the Assertion Quality Extension and that it be
> implemented to provide the more robust metadata such as what type of
> authentication was actually preformed.
>
> --David
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of john kemp
> Sent: Thursday, February 01, 2007 7:13 PM
> To: Granqvist, Hans
> Cc: OpenID specs list
> Subject: Re: Proposal: An anti-phishing compromise
>
> Granqvist, Hans wrote:
>
>>> Proposed Change
>>> ===============
>>>
>>> Add a single, required, boolean field to the authentication response
>>> that specifies whether or not the method the OP used to authenticate
>>> the user is phishable. The specification will have to provide
>>> guidelines on what properties an authentication mechanism needs to
>>> have in order to be "non-phishable." The field is just meant to
>>> indicate that the authentication mechanism that was used is not a
>>> standard "secret entered into a Web form."
>>
>> The receiver should decide what is 'non-phishable', not the
>> sender, so
>
>> it would be better if the OP just states what mechanism was used,
>> perhaps.
>
> Agreed. A statement as to the "phishability" or not seems to be too
> vague to be useful. A simple statement of the authentication method
> used
> would seem to give the same effect, while providing potentially useful
> information (assuming the RP trusts statements from the OP at all.)
>
>>
>>
>>> Benefits
>>> --------
>
> ...
>
>> Here's what I think:
>>
>> Since the association step is hardly ever used, it can much more
>> easily be overloaded with extra information without breaking any
>> implementation.
>>
>> If the OP would *require* an OpenID association step from the RP,
>> then
>
>> this step can include an exchange of meta-information between OP and
>> RP.
>
> How does the association step between OP and RP change the
> relationship
> between the OP and the user (agent)?
>
> I thought the attack we were considering is when a rogue RP directs
> the
> user agent to a rogue OP, who then steals the user's credentials?
> How is
> that affected by the rogue RP and rogue OP "associating"?
>
> - John
> _______________________________________________
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
> _______________________________________________
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>
_______________________________________________
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
