[stir] Re: Query-Scoped Communication Authority for 6G — Request for DISPATCH Feedback

[Sangam Das <[e-mail]>]

Dear Paul,

Thank you. Focusing on this one case is useful because your questions
expose where my first example compressed too many assumptions into the
sequence.

The 30-minute / two-attempt values were only intended to make the state
machine concrete. I agree that they are not realistic for a plumber
callback and should not be treated as protocol defaults.

More importantly, I did not state the user’s actual objective clearly
enough.

The use case is not simply:

“prevent the plumber from calling me again.”

It is:

“allow this selected plumber to contact me regarding this enquiry, without
requiring me to disclose a durable personal identifier whose possession
becomes indefinite future reachability authority.”

A more realistic example would be:

U searches a directory or marketplace for a plumber and selects:

“Request a quote / callback.”

U provides application-level information such as:

enquiry = kitchen pipe leaking
preferred-channel = voice or messaging
contact-validity = until tomorrow evening
selected-business = B

U may revoke that authority earlier.

D provides the enquiry information to B, for example:

“Kitchen pipe leaking; user requests a quote.”

Separately, B receives or can invoke an enquiry-scoped communication handle.

B does not need U’s permanent telephone number.

The corresponding authority means approximately:

B is currently authorized to contact U
regarding enquiry E,
through an allowed channel,
while that authority remains valid.

If the authority later expires or is revoked, possession of the visible
handle alone does not create continuing reachability.

That is the property I am trying to isolate.

The proposal is therefore not:

“the plumber must never call me again.”

It is:

“the plumber's possession of an identifier must not,
by itself, decide whether the plumber may call me again.”

If the relationship continues, U can extend the authority, issue another
authority, permit a longer service window, or convert B into an ordinary
contact.

So the system does not try to predict in advance whether U will appreciate
every future call. It separates identifier possession from current
communication authority.

On your specific questions:

What is D?

D is a discovery or transaction intermediary.

Examples of the class could include a map/business-search service,
local-services marketplace, insurer/home-services application,
classified-ad service, professional directory, etc.

Google Maps/Search is an understandable example of the class of service I
mean, although I am not suggesting that Google currently implements this
mechanism.

The same question arises whenever an intermediary introduces two parties
but disclosure of a permanent telephone number is undesirable.

How does D know which G is appropriate for U?

I agree that my first sequence assumed this away.

There needs to be a discovery mechanism.

For example, when U creates the enquiry-side communication capability, U’s
communications provider or account could associate it with a grant-service
identifier or authority realm.

Conceptually:

enquiry handle
    ->
authority realm / resolver
    ->
G

The originating side should not require bilateral configuration with every
possible G.

If every plumber or marketplace must integrate individually with every
recipient’s grant provider, the architecture does not scale as an Internet
protocol.

I have intentionally not fixed the discovery syntax yet because that seems
like one of the protocol questions that needs discussion.

Where does U’s communication policy come from?

I think I mixed two different things together in the earlier description.

There is a standing recipient policy, and there is a per-enquiry decision.

Standing policy might contain relatively mechanical constraints such as:

enquiry-based contact enabled/disabled
permitted channels
quiet hours
maximum authority lifetime
whether transfer to another sender is permitted
revocation behavior
whether renewal may be requested

That policy could reside with a carrier, communications provider,
OS/account-level communication service, or another grant service selected
by U.

Separately, when U presses:

“Request callback from this plumber”

U is making a specific authorization decision at that moment:

B may contact me regarding enquiry E.

The standing policy constrains what may be issued. The per-enquiry action
supplies the specific business and context.

I agree that a permanent communications policy should not try to predict
something like:

“Will I appreciate this plumber calling at 14:00 tomorrow?”

That is too subjective and dynamic.

Does D retain G1?

Not necessarily.

There are at least two possible models:

   1. G1 is a self-contained authenticated authorization object; or
   2. G1 is an opaque reference to authoritative state maintained by G.

In the second case D only needs to convey the reference.

Current state such as:

valid
revoked
expired
consumed / completed
renewed

can remain authoritative at G or at the enforcement service.

That model may also make immediate revocation easier.

Is this a token plus a human-usable identifier?

Conceptually, yes, but I would keep the two objects distinct:

H  = visible/query-scoped communication handle
G1 = authenticated communication authority,
     or a reference to that authority

Possession of H alone MUST NOT be sufficient communication authority.

That distinction is central.

The ordinary telephone-number model often combines several roles:

identifier
routability
practical ability to attempt communication

The proposal separates those roles.

How does B know what U wants?

Through D/application semantics, not through G1 itself.

For example:

Enquiry E:
    kitchen pipe leaking;
    user requests quotation.

G1 separately states, in machine-enforceable terms:

B may contact U regarding E.

I would not expect SIP signaling or an authorization object to carry the
complete plumbing request.

The enquiry identifier only binds the communication authority to the
application transaction so that the context cannot later be substituted
independently.

Must B know G?

Ideally no.

B should not need to know whether U uses carrier A, carrier B, an OS
communication broker, or another grant provider.

B’s originating communications service should be able to resolve the
authority using common discovery and carriage/retrieval semantics.

Again, if every business must integrate separately with every G, I would
consider that a failure of the architecture.

Who chooses voice or messaging?

U can authorize a bounded set of channels:

allowed-channels = {voice, messaging}

B may then choose one of those permitted channels.

The actual communication attempt might therefore be:

sender = B
recipient = U
enquiry = E
channel = voice

The terminating side checks that voice is within the authority granted for
E.

So I do not think G1 necessarily needs to select one immutable carriage in
advance.

Does carriage require new support?

Yes.

If the whole mechanism exists only inside one marketplace, it can be
implemented as an application-local callback system.

For this to become an interoperable Internet/communications mechanism, the
originating and terminating infrastructure need some common way to:

discover the authority,
convey or reference it,
authenticate it,
obtain current state,
and enforce it before recipient-visible communication occurs.

I left the exact carriage open because I do not yet want to prejudge
whether the appropriate mechanism is:

a SIP extension,
an authenticated signaling claim,
URI/handle resolution,
pre-INVITE authorization retrieval,
or some combination.

But your interpretation is correct: the terminating enforcement point needs
enough authenticated information to make the decision before ringing,
notification, accepted session, or equivalent recipient-visible effect.

That is new machinery.

The architectural question is whether separating persistent identity from
current reachability authority provides enough benefit to justify
interoperable machinery rather than leaving this entirely to individual
applications.

What about the two-attempt limit?

I agree that it is the wrong primary abstraction for this use case.

A more realistic authority might simply be:

business = B
enquiry = E
channels = voice or messaging
valid-until = tomorrow 20:00
revocable = yes

Optional abuse controls may exist, but they are secondary.

The protocol would also need to distinguish carefully between:

SIP/network retransmission,
unsuccessful human contact attempt,
successfully established communication,
and a genuinely new communication after a completed interaction.

Those should not automatically consume authority in the same way.

So I think your questions point to a better worked example:

an enquiry-specific callback authority with a realistic validity period,
explicit discovery of G, explicit renewal/revocation, and a clear
distinction between enquiry information and communication authority.

They also identify four areas the draft needs to make much more concrete:

   1. discovery of G;
   2. separation of standing policy from per-enquiry authorization;
   3. handle/authority resolution and carriage; and
   4. lifecycle semantics after initial contact.

That seems like a much better basis for deciding whether there is actually
an IETF protocol problem here.

Thanks,
Sangam




On Mon, 31 Aug 2026 at 11:41 PM, Paul Kyzivat <[e-mail]> wrote:

> On 8/31/26 12:20 PM, Sangam Das wrote:
> > Dear Paul,
> >
> > Agreed. Below is use case 1 as participants, order, and inputs. Two
> > sibling cases use the same sequence.
> >
> > *Use case 1 — map enquiry*
>
> Lets just focus on this one for now.
>
> What is the user's goal? It seems like he must want to negotiate with a
> plumber to obtain some plumbing service. I would think the
> straightforward way to do this would be to call the voice number of the
> plumber and talk with him. This is different from that.
>
> Perhaps the user visits the web site of the plumber, fills out a form
> describing what he needs, and leaves some sort of contact information so
> the plumber can call him back. Is that it?
>
> > Participants:
> >
> > U  user / intended recipient
> > D  map or directory service
> > G  grant service (may be part of D, a carrier, or recipient-side)
> > B  business / plumber seeking to contact U
> > T  terminating enforcement point (SBC, SIP AS, or CPaaS)
> >
> > *Order*
> >
> >  1. U searches D and selects “contact” for B.
> >     Input: current search result identifying B.
> >  2. D asks G for communication authority.
> >     Input:
> >
> >     sender = B
> >     recipient = U
> >     purpose = enquiry-id
> >     channel = voice or messaging
> >     expiry = now + 30 minutes
> >     max-attempts = 2
>
> I don't think this is realistic for any plumber I know.
> Its really hard to predict when the plumber might get around to calling
> back - it might easily not be till the end of the day, or tomorrow
> morning. And U might not be available continuously during that time, so
> it might take more that two attempts to find a time when U & B are
> concurrently available.
>
> Can you give a real world example of D? Google search?
>
> Also, How does D know what G is appropriate for contacting U?
>
> >  3. G checks U’s current communication policy. If permitted, G creates
> >     grant G1 covering those fields.
>
> How? Presumably this U must have previously set up this communication
> policy. Can you explain this process, and the sorts of things U should
> enter into it, and where it resides?
>
> I gather that D must retain GI as persistent state, until the contact is
> completed or expires?
>
> >     Output: G1 or a reference to G1, plus a visible handle that is not
> >     by itself general authority to reach U.
>
> A token and a human-usable identifier for it?
>
> >     The sender, recipient, purpose identifier, channel, expiry, and
> >     attempt limit must be authenticated as part of G1, or authenticated
> >     state referenced by G1. They must not be caller-supplied decoration
> >     that can be changed independently.
> >
> >  4. D shows B a “call / message user” control associated with G1.
> >     Input: visible handle and G1.
>
> How? This is the first B has heard of U. So this presumably must
> describe what it is that U wants. In the real world today, this is
> likely to be a voicemail message, or an email.
>
> Also, must B have prior knowledge of G? (Presumably different users may
> choose to use different grantor services.)
>
> >  5. B initiates the call or message.
> >     Input: handle plus G1 or a reference to G1. >     Carriage remains
> open: SIP header, PASSporT-related claim, or
> >     pre-INVITE authorization retrieval. Origin may separately be
> >     STIR-attested.
>
> Apparently G1 must specify the sort of carriage, chosen by B from
> alternatives offered by U. Where does all of this get set up?
>
> >  6. T receives the request before ringing, recipient notification, or
> >     session acceptance.
> >
> >     Input: signaling, G1 / grant reference, and authenticated origin.
>
> So whatever carriage is used must have support for conveying G1, and
> acting on it.
>
> >     T verifies that G1:
> >
> >     exists and is authentic;
> >     is unexpired and unrevoked;
> >     has remaining attempt authority;
> >     is bound to authenticated sender B;
> >     identifies U as recipient;
> >     authorizes the requested channel;
> >     carries the same authenticated purpose identifier required for this
> >     act; and
> >     has not already been consumed beyond its permitted use.
>
> I gather support for grants like this is something new that has to be
> created and deployed?
>
> >     T is not required to infer whether the human conversation really
> >     concerns “plumbing”; the semantic definition and issuance policy for
> >     |enquiry-id| belong to the policy/application layer. The protocol
> >     requirement is that the purpose identifier used for authorization
> >     cannot be substituted after grant issuance.
> >
> >  7. Decision.
> >
> >     Success: T permits ringing or delivery and consumes or reserves one
> >     logical communication attempt.
> >
> >     Failure: T rejects, for example with an appropriate SIP failure
> >     response. No ringing, recipient notification, accepted session, or
> >     media allocation is released beyond T through the controlled path.
> >
> >     A SIP retransmission of the same logical attempt would not itself
> >     consume another quota unit; retransmit-versus-new-attempt semantics
> >     would need to be defined by the protocol.
> >
> >  8. After 30 minutes, revocation, or two consumed logical attempts, B
> >     may still hold the visible handle. That possession does not create a
> >     path to U. A later contact requires new authority.
>
> All this is to prevent the plumber from calling me back again?
>
> ISTM that there are both cases where I would appreciate the call, and
> where I wouldn't. I doubt I could reasonably describe this in advance in
> my communications policy.
>
> I don't think I can meaningfully say more until I read your followup to
> the above.
>
>         Thanks,
>         Paul
>
>