- From: Adam Bergkvist <adam.bergkvist@ericsson.com>
- Date: Mon, 2 Jul 2012 14:32:31 +0200
- To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
- CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
On 2012-06-22 17:58, Cullen Jennings (fluffy) wrote: > > On Jun 12, 2012, at 1:31 , Harald Alvestrand wrote: > >> On 06/11/2012 12:23 PM, Cullen Jennings wrote: >>> This is related to Anant's proposal but my summary of what I >>> thought I heard was: >>> >>> IceServers becomes an array of IceServer objects. >>> >>> The IceServer object has an URI attribute and a nullable password >>> attribute and we will figure out what realm is and where it >>> goes. >> I think I heard Anant or Dom suggesting that it should be an URI + >> an Origin (an Origin has fields for a domain and an >> username/password). But that's purely for syntax reuse; we've got >> to put something in there that contains the info ICE needs in order >> to authenticate successfully both for STUN (short-term credentials, >> if any) and TURN (long-term credentials). > > Can someone educate me about Origins? I understand the idea of same > origin from security point of view but not seeing how it applies > here. > One reason to use the origin in such a case is to provide information that cannot be set by the application. For example, if all authentication information can be set by the application, then I can simply copy it from another web service and pretend to be that service towards other boxes in the network. /Adam
Received on Monday, 2 July 2012 12:32:55 UTC