Sam Hartman <[EMAIL PROTECTED]> writes: >>>>>> "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.
And I never said otherwise, but just being a defense does not make it a requirement. -Ekr _______________________________________________ dix mailing list [email protected] https://www1.ietf.org/mailman/listinfo/dix
