docs(rooms): describe the two gaps as fixed, not as caveats - #1276
Merged
Conversation
Two of the four findings the guide surfaced are closed by #1274 (registration is authorized: the signer must be the owner it names) and #1275 (the role an agent runs as carries the room capabilities). The guide described both as live gaps, so it goes stale the moment either merges. The room-creation caveat becomes what creation actually checks, and what it still does not: the request's own proof establishes the owner, and nothing yet governs which parties may create a room on a given host. The agent-capability catch becomes how to grant the oracle - by role, since the per-entry capability list is descriptive rather than enforced, which is worth saying where an operator would otherwise reach for it. Both the markdown and the HTML page carry the same correction, plus a refusal-table row for the registration error an operator will now meet. Signed-off-by: Glenn Gore <glenn.g@affinidi.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #1273, which merged while the two defects it surfaced were being fixed.
The guide describes both as live gaps, so it goes stale the moment either of #1274 / #1275 lands. This corrects both, in the markdown and in the HTML page:
rooms/create/0.1is not authorized on either host; anyone who can reach the endpoint can register a room row") becomes what creation now checks, and what it still does not: the request's own proof establishes that the signer is the owner it names, while which parties may create a room on a given host remains ungoverned untilrooms.regolands. Step 3 of the walkthrough now says to sign that one call as the owner, since that is a thing a caller has to get right.Role::Applicationcarries neitherroomPresentnorroomOpen") becomes how to grant it: by role, withapplication/initiator/admincarrying both andreader/monitorcarrying neither. It also says the per-entrycapabilitiesfield is descriptive rather than enforced, which is worth stating exactly where an operator would otherwise reach for it.Plus a refusal-table row for the registration error an operator will now meet.
Merge after #1274 and #1275 — this describes their behaviour. If either is rejected, say so and I will put the caveat back rather than the fix.