From 05868742405139ed7e683dcd52a0ad0c3a8d4d9b Mon Sep 17 00:00:00 2001 From: Michiel De Backker Date: Mon, 4 Dec 2023 17:20:29 +0100 Subject: [PATCH] Separate tracking issue --- index.bs | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/index.bs b/index.bs index 61c6083..a689692 100644 --- a/index.bs +++ b/index.bs @@ -49,9 +49,10 @@ Known peers {#known-peers} The user agent should maintain a list of peers that it has knowledge of. The [=local peer-to-peer manager=] has an associated known peers map, an [=/ordered map=] of [=known peers=]. Each known peer is a [=peer=] that has an associated authentication state and peer grant state. The user agent keeps track of the [=authentication state=] per peer and the [=peer grant state=] per peer, per origin. Unless [=persisted=], both the states are initially false. + Note: The [=peer grant state=] is origin-level while the [=authentication state=] is peer-level. The rationale is to not require the user to undergo authentication multiple times between the same peers. This design may change informed by security and privacy considerations. -Issue(wicg/local-peer-to-peer#15): See also related +Issue(wicg/local-peer-to-peer#24): See also related The user agent may persist known peers, their authentication state and/or peer grant states. If the user agent chooses to do so, it must do so in accordance with the [[!openscreenprotocol|OpenScreen Protocol]] Persistent State rules. Such a peer or its state is said to be persisted.