Summary

  • RFC 5360 treats consent as permission stored beside a relay's translation logic. An administrator's accepted request to add a URI does not authorize delivery; the proposed recipient remains pending until a bounded permission is granted and installed.
  • A permission document binds sender scope, original-recipient or target URI, final-recipient URI, and grant or deny capabilities. Authentication of the person invoking a capability and a later runtime match are separate receipts from the document itself.
  • Credit-based one-recipient manipulation, 470 Consent Needed, refresh, removal and Trigger-Consent revocation constrain amplification and stale authority. None of them alone proves correct fan-out, endpoint delivery, human attention or that revocation stopped every residual path.

202 is a queue receipt

The prototypical flow begins with user A manipulating a relay's resource list. A asks to add B as a recipient. The relay accepts the HTTP operation with 202 and places B in a pending state because B has not yet permitted the translation.

That response is useful. It says the relay accepted responsibility for further processing. It does not say B approved, the translation was installed, a later request matched it, an outgoing message was sent or B received anything.

RFC 5360 gives the client a separate Pending Additions event package precisely because those outcomes can occur later. States include pending, waiting, error, denied and granted. If B is offline without store-and-forward, the permission MESSAGE may fail and A needs to learn that result rather than interpret the earlier 202 as eventual success.

Operational systems often compress asynchronous work into a single green verb. Here that would collapse the proposal, consent request, recipient decision and installed state. Preserve the original manipulation ID, target URI, proposed recipient, response, pending-state version, subsequent NOTIFY events and the exact transition that made the recipient eligible for translation.

An accepted edit is authority for the relay to continue the consent workflow. It is not authority to send future traffic to B.

Consent lives where translation is executed

A relay receives a request addressed to a target URI and maps it to one or more recipient URIs. It may be a proxy, a B2BUA or a hybrid. The mapping can come from registration, a URI list or other local data.

That translation is the control surface. One incoming request can become several outgoing requests. Even a one-to-one mapping can redirect traffic toward a party that did not ask for it. One-to-many mapping adds the possibility that a small client action produces much more relay traffic.

RFC 5360 therefore associates permissions with the relay's translation logic. A recipient that has not given permission is ignored when the relay performs the translation. The address book entry or configuration proposal is not enough; the component that creates outgoing requests must keep the consent state it will enforce.

This location matters for evidence. A client screenshot can prove an attempted list edit. A recipient's grant can prove one decision. Neither shows which version of the relay's mapping was active when a later INVITE or MESSAGE arrived. The run needs a match receipt joining sender scope, target URI, final recipient, permission version and outgoing request.

If a B2BUA terminates and recreates requests, its custody differs from a proxy's. Calling both “the list service” is not enough to assign responsibility. Name the relay, its role, its translation version and every point where an incoming identity is changed or reasserted.

A list administrator cannot volunteer another person

Relays usually authenticate and authorize clients before allowing configuration changes. That control is necessary, but RFC 5360 says it does not solve the consent problem. An authorized client may still add an unwilling recipient.

This is an important separation of authority. The list administrator may be allowed to propose membership. The recipient remains the authority for whether the relay may translate traffic toward their URI in the described context.

An audit should retain both decisions. Who authenticated the administrator? Which policy allowed the proposal? Which recipient identity was asked? Which translation did the recipient see? Who authenticated the grant? Combining those into “member added by an authorized user” hides the very protection the framework introduces.

The distinction becomes sharper with public or shared lists. Ownership of the target URI, control of its configuration and consent of every final recipient are different facts. A group name cannot absorb individual permission.

Permission is a tuple, not a generic yes

The permission document describes what is being authorized. It contains the identity of the sender, the original recipient or target URI, the final recipient URI, and URIs that can grant or deny the permission.

The sender field can be broad, and the target can be wildcarded under the document model. The final recipient cannot be wildcarded. This asymmetry prevents “I consent somewhere” from becoming authority to send to arbitrary destinations.

Yet even a syntactically correct tuple needs operational context. Was the human-readable part consistent with the machine document? Were both protected against modification? Did the interface display the sender and target scope? Did the person understand whether the grant covered one list, any target or any sender?

Store the exact permission-document bytes and a normalized interpretation. Preserve the sender, target, final recipient, grant and deny capabilities, creation time, relay identity, format version, integrity context and human-readable presentation hash.

A later request should be matched against that frozen scope. If the list target changes identity, an alias is repointed or a sender wildcard begins covering a new population, the old grant must not silently acquire new meaning.

A grant capability must still reach the right principal

The recipient grants or denies by sending an empty-body SIP PUBLISH or HTTP GET to one of the capability URIs in the document. The empty body does not make the operation context-free. The URI carries the connection to a particular permission.

The relay must ensure the action came from the final recipient, not an attacker. RFC 5360 describes SIP Identity, P-Asserted-Identity within a trusted administrative domain, SIP Digest for a shared-secret relationship and return routability.

Each method has different custody. A trusted-domain assertion depends on the administrative boundary. Digest depends on secret ownership and challenge state. A signed identity needs the applicable identity mechanism and owner comparison. Return routability proves something narrower: the actor could receive and use an unguessable capability delivered along the protected route.

Do not store only “authenticated: true.” Record the method, asserted principal, validated recipient URI, trust domain or credential context, capability hash, policy version and decision. A method that is adequate for one architecture may not prove the same identity claim after a trust boundary moves.

The RFC requires the relay to compare the originator with the owner of the recipient URI for the identity-based methods. Correct credentials for a different principal are not consent.

Return routability proves possession, not durable identity

RFC 5360 presents return routability as weaker than SIP Identity but useful where the stronger mechanism was not widely available. The relay generates an unguessable URI and delivers it in the permission request. A request to that URI can be treated as authenticated under the framework's conditions.

Those conditions carry the protection. The MESSAGE must go to a SIPS URI, the grant and deny capabilities must be secure SIP or HTTPS URIs, and the random portion must contain at least 32 bits of cryptographic randomness.

Even when every requirement holds, the result is bounded. It proves possession of a secret capability delivered to a reachable endpoint. It does not independently prove a person's civil identity, continuing control of the address, informed understanding, or that a forwarded store-and-forward copy was not exposed.

The evidence record should retain generation quality, entropy claim, capability hash rather than reusable plaintext, protected delivery route, redemption time, source context and single-use or replay treatment. If the capability leaks, the subsequent request can look formally valid while losing its intended relationship to the recipient.

Migration from return routability to stronger identity also changes the acceptance rule. A relay that begins requiring SIP Identity can reject grants that previously worked. Version that policy instead of rewriting history as though old and new receipts were equivalent.

One recipient per transaction is bandwidth credit

The relay itself can amplify the permission-request phase. An attacker could add a large batch of recipients with one small configuration operation and cause the relay to send a MESSAGE to each address.

RFC 5360 counters this with a credit-like constraint: the party adding recipients should generate bandwidth comparable to the relay's requests. XCAP clients may not add more than one recipient per HTTP transaction; REGISTER clients may not add more than one contact per transaction under this framework.

This is not a universal rate limit and does not prove benign intent. An attacker can still issue many transactions, use many identities or distribute activity over time. The rule removes one asymmetry: one configuration request cannot directly purchase a much larger permission-request fan-out.

Monitor client identity, target URI, transaction size, proposed recipient, bytes in and expected bytes out, rate and rejection. A 409 or 403 records enforcement of the transaction bound. It does not prove the wider system stayed below a safe aggregate rate.

The control is strongest when paired with budgets across accounts, targets and destinations, plus evidence that retries and store-and-forward do not recreate hidden amplification.

470 makes one missing permission stop the list

Request-contained URI lists select recipients at communication time rather than installing one fixed list for every translation. The relay maintains a superset of recipients from whom it has permission, then checks the particular list in the incoming request.

If even one URI lacks permission, the relay must not perform the translation and should answer 470 Consent Needed. Permission-Missing identifies the affected URI or URIs.

The all-or-nothing rule prevents a partial fan-out from being reported as an ordinary failure. A system that sends to permitted entries and silently drops the rest has executed a different policy and may leak group composition through uneven results.

Retain the incoming list hash, the permission-set version, every match result, the 470 response and any disclosed missing set. The missing set can itself be sensitive, so diagnostic access should be bounded.

The captured errata page shows one Reported technical report concerning angle brackets when URI punctuation would make Permission-Missing ambiguous. That report is dated evidence about a proposed clarification, not permission to treat the original RFC as already rewritten.

Revocation is a state transition with a recovery path

A recipient can revoke by using the deny capability from the permission document. If the capability is lost, a later translated request may contain Trigger-Consent, including the target URI. The recipient can use that trigger to request a new permission document and then deny.

This recovery design is practical, but it exposes a gap between wanting to revoke and completing revocation. The recipient may need to receive another unwanted request before discovering the trigger. The relay must correlate the trigger capability with the final recipient and target. A 200 response to the trigger only begins recovery; it does not mean the old permission has been removed.

An honest revocation ledger records intent, trigger request, new document issuance, authenticated denial, permission deletion, translation-logic version and the last outgoing request under the old grant. Concurrent requests need a defined cutover.

Permissions should also disappear when their context disappears. Removing a recipient should delete the related permission. Expiring a registration should remove the contact's permission. Periodic refresh is recommended, and failure to refresh should delete the permission, but the RFC leaves interval selection to applications.

Therefore “not explicitly revoked” is not a timeless grant. Context, freshness and removal rules are part of authority.

Third-party registration separates binding from permission

REGISTER traditionally sets up a mapping and authorizes its use together when the registrant and later recipient are the same party. Third-party registration breaks that assumption: an attacker can bind the attacker's Address of Record to a victim's contact and direct unsolicited traffic at the victim.

Under the framework, a 202 for the third-party registration leaves the contact pending while the registrar seeks consent. The pending-additions event reports the later status.

This is not an argument that every ordinary registration needs an extra consent ceremony. RFC 5360 notes the different trust case for a user agent that registers and receives on the same connection, and the different risk for registrars that accept third-party registrations.

The evidence must name which case applies. Preserve the AoR, contact, authenticated registrant, connection relationship, third-party flag, pending state, permission tuple and eventual forwarding decision.

“REGISTER succeeded” is otherwise too large a claim. It can mean the server accepted a request for processing, not that it acquired authority to forward calls to the contact.

Encryption protects the document, not the interpretation

Permission documents and pending-addition status reveal relationships among senders, targets and final recipients. An attacker who modifies a document can make a person grant something different from what the interface appears to ask.

The RFC recommends strong integrity and confidentiality, discussing end-to-end protection such as S/MIME and hop-by-hop TLS/SIPS when stronger means are unavailable. Store-and-forward systems need protected delivery even when their client interface is not SIP.

These controls protect transport under their assumptions. They do not prove that the human-readable part matches the machine part, that the UI exposed a wildcard, that the correct principal clicked, that the relay installed the same tuple or that later matching was correct.

Compare both representations before presentation. Bind the displayed text to the document hash. Record transport and content protection separately. Test mutation, replay, capability leakage, stale pending state and policy changes.

The goal is not to diminish encryption. It is to stop channel security from borrowing authority over consent semantics and enforcement.

The document has a later syntax clarification, not a deployment receipt

RFC 8217 updates RFC 5360 among several SIP documents to clarify when a URI must use the name-addr production. That relationship changes the normative parsing environment for affected fields.

It does not demonstrate that a relay implemented the update or that an old capture can be reinterpreted without knowing the parser and software version. Keep the governing document set beside each execution.

Likewise, publication as a Proposed Standard establishes a standards-track artifact. It does not prove adoption, interoperability or operation in a named service. A current implementation claim requires product and runtime evidence.