> -----Original Message----- > From: Dean Willis [mailto:[EMAIL PROTECTED] > > Dude, go talk to your lawyer. > > I'm NOT talking about a foreign identity service that is the source of > caller-ID fraud. I'm talking about an allegedly trustworthy identity > service that is culpably negligent because it has allowed itself to > become a conduit of identity fraud. > > If you're a US business, and you sign a a request containing a > telephone number, and it turns out you're wrong (not because you're > doing it on purpose, but because you are incompetent) and I get taken > in by a scammer as a result of your mistake, I can sue you for all the > damages I receive. I might even win, and at the very least, I'm going > to cost you a big chunk of money.
Yes, and you mistook my premise I think - I was not arguing about that for a US firm (heck, in the US you could sue even without a signature ;) - I was arguing about it for a foreign one. Whether a US-based identity issuer (e.g., Verisign) has that liability for certs it gives out to foreign entities I don't know, IANAL, and isn't germane to my argument (I think). > But if you signed the request with a stipulation that you passed the > request on, but that the identity came from the PSTN and is not > something you have verified (and these things are true), then you are > NOT liable, because there is no genenral expectation that PSTN caller > ID is absolutely correct. Then everyone would set this source=unverified param, even those that have very reasonable expectation of it being legit, and we wouldn't get the semantic difference we're looking for. > Given this, and in the absence a mechanism for making a disclaimer, > you WOULD have to be a fool to slap an identity header on something > that you didn't authenticate. Then I think anyone would have to be a fool to slap an identity header on anything, including things they authenticated. SIP's trust model simply isn't HTTP's, even with SIPS and TLS and all. It isn't even really the same as email's, though certainly closer. -hadriel _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
