Mihez fér hozzá
Az őszinte határvonal.
Az eszközök létezését a szerepköre dönti el
A kiszolgáló az Ön nevében jár el, azzal a kapcsolattal szemben, amelyet aktívvá tett. Nincs külön szolgáltatásfiók, és nincs szélesebb hozzáférés a sajátjánál. Amióta a szerepkörök megjelentek, a SZEREPKÖRÉNÉL sincs szélesebb hozzáférés. A kliensnek átadott eszközlista az aktív munkaterületen birtokolt jogosultságokból épül fel, így egy Viewer szerepkörű felhasználó kliense a sendEmail, a createRule vagy a sendWithTemplate eszközt egyáltalán nem sorolja fel.
Ez erősebb dolog, mint a hívás visszautasítása. A listáról hiányzó eszközzel a modell nem számol, nem eszik kontextust, és nem lehet valaki nevében megpróbálni, majd bocsánatot kérni érte. Azt is jelenti, hogy az üresnek tűnő kliens rendszerint egy hiányzó jogosultságot jelez, nem a kiszolgálóból hiányzó funkciót – pontosan ezt hivatott megmondani a whoAmI.
A regisztráció és a meghívás két kapu, és csak a második tart. A lista egyszer épül fel, a munkamenet megnyitásakor, a setActiveConnection pedig átviheti a munkamenetet egy olyan postafiókba, ahol kevesebbet tehet, így a lista a szerkezetéből adódóan elavul, a protokollnak pedig nincs módja eszközt visszavonni munkamenet közben. Ezért minden jogosultsághoz kötött eszköz futás előtt újra feloldja a szerepkörét az AKTUÁLIS kapcsolattal szemben. A regisztráció az udvariasság; a határvonal a meghívás.
A visszautasítás mindkét felét megnevezi, például Refused (missing_permission): your role in this mailbox is Viewer, which does not include “Send email”, így az ügynök el tudja magyarázni annak, akinek dolgozik, és abbahagyja a próbálkozást, ahelyett hogy egy átláthatatlan hibát ismételgetne, amíg valaki fel nem adja. Ha egy rendszergazda nyitott munkamenet közben módosítja a szerepkört, az ugyanígy csapódik le, mindjárt a következő hívásnál.
A másik tengely a címek, amelyeket mindez nem érint. A szerepkör azt mondja meg, mit tehet; a megkapott címek azt, mely postafiókokon teheti, és mindkettőnek egyet kell értenie, mielőtt üzenet megy ki.
Maga a token továbbra is hatókör nélküli
Ami NEM változott, az a hozzájárulás. Az alkalmazás által kapott token mindenhez elér, amit a szerepköre enged, nem pedig egy olyan részhalmazhoz, amelyet a jóváhagyáskor kiválasztott, tehát egy kliens jóváhagyása mindannak a jóváhagyása, amit Ön abban a munkaterületben tehet. Megmutatjuk, mi kér hozzáférést, mielőtt bármit megadnánk, és a Fiók → Csatlakoztatott alkalmazások utólag el is távolítja, törölve minden tokenjét és a mögötte álló jóváhagyást – a „csak olvasás, ennek az alkalmazásnak” választása viszont nincs megépítve.
Egy MCP-kliens plafonja tehát az ÖN plafonja. Ha szűkíteni akarja, mit tehet egy alkalmazás, az azt csatlakoztató személy szerepkörét kell szűkíteni, ami azt is szűkíti, mit tehet az illető az alkalmazásban. Ez ma az őszinte helyzet, és ezért érdemes még mindig megépíteni a hozzájárulásonkénti hatókört.
A szókészlet már közös: egy szerepkör jogosultságai és egy API-kulcs hatókörei ugyanabból az ábécéből származnak, és ettől számítható ki a kulcs jogosultsága a kettő metszeteként. A hozzájárulásonkénti MCP-hatókör is ugyanezekkel a szavakkal lesz kifejezve, amikor megérkezik.