On Apr 4, 2008, at 1:20 PM, Michael Thomas wrote: > Elwell, John wrote: >> Michael, >> >> The proposed indicator is probably better described as "not verified" >> rather than "limited guarantee of authenticity". But maybe, as has >> also >> been suggested, we simply should not use RFC 4474 on requests from a >> PSTN gateway. >> > > Rather than work on a solution, I'd rather hear why a receiver cares > about any of this. Ie, what does the consumer of this information do > differently? The experience from the email world thus far is "not > much" > which makes me suspicious this is too abstract a problem for the > outside > world to care about. >
That's a fair question. The worry is that an RFC 4474 identity assertion forms what is essentially a contract verification "I, identity service example.com, have verified according to best current practices that the party originating this message is authorized to use the identity sip:[EMAIL PROTECTED] ". We generally assume the "best current practices" something on the order of "the party in question has presented credentials based on a secret known to sip:[EMAIL PROTECTED] and presumably unknown to other parties, and this presentation is consistent with prior interactions had by this identity service and sip:[EMAIL PROTECTED]". But when the identity assertion is coming from a PSTN caller ID, it's significantly less authoritative statement: "I, the identity service at example.com, think that this request came from +12142821376 because this is the calling party identifier presented to my telephony interface." There is a profound liability distinction between these two. Failure to resolve it means that RFC 4474 identity headers would never be more credible than PSTN caller-ID, and we seem to think they need to be more credible. > A far more important question to be asking IMO is what will drive > 4474 _deployment_, rather than adding bells and whistles to it. Until > there's something of a critical mass then it's pretty much just > speculation > about the real life concerns. Of course it will be driven be legal requirements around call- traceability, logging (especially in the financial services business) and intercept. Nobody cares about spam. -- dean _______________________________________________ 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
