This is similar to the Chromium issue https://bugs.chromium.org/p/webrtc/issues/detail?id=4907 Initial analysis for prioritization: The key purpose of this is to allow short-lived access to TURN resources without having a tight binding between the web server and the TURN server. The fact that it’s using a different STUN attribute (than password) to communicate the access token is really protocol hygiene. It doesn’t make anything possible that wouldn’t otherwise be possible. So early implementations can use the technique described in here, but with normal TURN passwords holding the tokens. For this reason, we are putting this on our longer term roadmap, not our short-term roadmap. If anyone feels this should be done on the short-term roadmap, please make the argument in this bug.
Until support for TURN OAuth is generally available in WebRTC browsers, implementors may wish to look at the technique described in https://tools.ietf.org/html/draft-uberti-behave-turn-rest-00 -- it requires no browser support, and only moderate coordination between the application (web) server and the TURN server.
Mass change P2->P3 to align with new Mozilla triage process.