>>>>> "Eric" == Eric Rescorla <[EMAIL PROTECTED]> writes:
>> I don't believe that my requirements would require that the
>> relying party talk to the identity provider. I believe that
>> assuming a reasonable set of trust anchors, having the web
>> browser ask the identity provider if the dnsname is allowed to
>> accept the identity. That provides a protocol hook allowing
>> the identity provider to meet the requirement that it MUST
>> confirm the relying party is a valid relying party for the
>> identity. If the relying party later proves that it has a
>> trusted certificate for this identity it meets the second
>> requirement.
>>
>> Can you suggest clarifications to the text?
Eric> I don't think so because we don't agree on the
Eric> requirements. My point is that the relying party does not
Eric> need to prove its authorization to the identity provider in
Eric> any way in order to solve the phishing problem.
OK, we disagree on the requirements. I believe that allowing the
identity provider to validate the identity actually provides
significant defenses against phishing.
Assume that examplebank.com is a financial institution that acts as an
identity provider for themselves and for business partners. If they
are given the ability to confirm that the website I'm going to is
allowed to accept their identity, then they can give me an error if I
attempt to use their identity with some random phishing site I got a
link to in email.
You may disagree that this defense is important. However it is a
defense.
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
