On Feb 20, 2008, at 3:47 PM, Paul Kyzivat wrote: >> . > > *ANY* anonymization service will have this problem. It can know who > *it* is getting the message from, but it cannot know if that source > is acting as a relay point. If it can't provide identity without > knowing that then it can never provide identity.
We have traditionally presumed that if the party requesting anonymity/ identity can pass a digest authentication or equivalent test that some level of assertion about the identity of that party is warranted. > > >> Conversely, there is a legitimate role for a service that is both >> an anonymizer and an asserter of identity. The assertion here is >> "I know who this person is, but I'm not telling you without proper >> cause". As an end user, I'd be inclined to grant this a higher >> level of trust than I would a message that claims nothing about >> who it might be from. > > Yes, I guess there could be some value in such a thing. But it will > only be valuable if the recipient of the identity can determine it > has this property. > > If I get a call from an address I don't recognize (which is > typically be the way I will see it if there is an anonymizer > involved) then how am I to know: > - this is an anonymizer (as opposed to a direct call from somebody > I don't know) the anonymizing identity service has an included an Identity header signed by the identity service. That's different from NOT having one. Consider the difference between a SIP request with a "From:" of "[EMAIL PROTECTED] " and the same request carrying an RFC 4474 Identity body that is signed with the FBI.GOV cert (which validates back to a trusted root). Or consider the difference between this message, and a similar one signed by the self-signed cert for "john smith". As in all certificate work, you have to have knowledge of the policy and role of a signer in order to decide what sort of trust you wish to extend to it. > > - that this anonymizer will be willing and able to disclose the > identity under certain circumstances > - what those circumstances are I see this is more a function of "identity" than "anonymity". If you act as an identity service, whether anonymizing or not, then you probably need a policy statement about your identity service just as every CA needs a policy statement about its credential service. But mosly, it comes down to a trusted relationship. A signature from an anonymizing identity service that you don't trust obviously adds no value. Let's talk about the context of eBay. Buyers and sellers occasionally communicate outside of the offer-bid cycle. This has raised the opportunity for all sorts of fraudulent activity, such as forged "2nd- chance" offers. Ebay found it necessary to put in its own messaging infrastructure which provides for authenticated transmission. If you get a message in that channel claiming to be from the seller of an item on which you are bidding, there is a much higher probability that this is true than if you get such a message from a 3rd parry email server. Here, eBay is acting as an identity service -- somebody presumably had to be able to log into eBay as the seller in order to be able to send the message. The seller is still more-or-less anonymous -- we don't know who they are -- but eBay has vouched for their role, and we know that if things go bad, they'll attempt to apply their published policy in resolving the situation. Extending to the SIP anonymous/pseudonymous/identity discussion, I might get an INVITE from "Anonymous" that carries an Identity header verifiably from eBay. From this, I'd know that the party contacting me has a verified relationship with eBay, and I'd be able to make some decision about that message that might be a different decision than if the Identity header were not present. And yes, there's all sorts of room for SAML-like things added to Identity headers. -- Dean _______________________________________________ Sip mailing list http://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
