W protokole JV, opartym na podstawach DH, w pierwszym etapie dwaj sąsiadujący członkowie stosują protokół wymiany kluczy i ustanawiają wspólny klucz. W drugim etapie każdy członek nadaje Wi, = Ki/Ki-1 gdzie Ki jest kluczem dzielonym między i-tego a i + 1-tego użytkownika. Każdy użytkownik oblicza klucz grupy jako Ki-1nWin-1Wi+1n+2….Wi-2 = K1K2…Kn .W tym protokole penetrator może obliczyć klucz wymieniany między parą użytkowników, jeśli zna zarówno klucze długo-, jak i krótkoterminowe co najmniej jednego z n użytkowników. Stąd prawdopodobieństwo poznania klucza sesji wynosi 1– (1 – 2p2)n, a więc DPFS wynosi 1- (1 – 2p2)n. Liczba rund to dwa. Jeśli jest jeden słaby (o niskim zaufaniu) uczestnik, oba jego klucze mogą zostać przejęte. Stąd |x| byłoby 1. W przypadku subskrybowanego czasopisma możliwość kompromitacji kluczy z powodu jednej osoby nie jest pożądaną właściwością. Stąd, mimo że liczba rund wynosi dwa, nie jest to zalecane. Dla tablicy interaktywnej |x| = 2 jest pożądaną właściwością, ponieważ możliwe byłoby częste przeliczanie kluczy. Wartości zaufania grupowego mogą być zazwyczaj mniejsze niż BD, ponieważ niższe wartości zaufania dla dowolnego uczestnika mogą znacznie obniżyć wartość zaufania poniżej 1. Jednak, jak wspomniano wcześniej, zaproszeni członkowie tej aplikacji mogą mieć wysoki wynik zaufania. Biorąc pod uwagę oba aspekty, JV byłoby zalecane dla tablicy interaktywnej. W aplikacji do spotkań zarządu, gdzie zwykli członkowie mają wysokie wartości zaufania, JV zapewniłby wysoki GTS, ponieważ byłby tylko jeden użytkownik z niższym wynikiem zaufania, a szanse na długoterminowy klucz nawet nieszczelnego uczestnika zagrożone są prawdopodobnie małe. Ponowne przeliczenie kluczy jest łatwe, ponieważ liczba rund wynosi dwa. Biorąc pod uwagę te dwa aspekty, JV jest słabo zalecanym protokołem do spotkań zarządu.