My understanding is since the plan-id is issued to a client by the server,
server is aware of authenticated principal / roles, the server knows who
this plan-id was issued to, so that it can then later authorize based on
that and bubble up appropriate 403 error codes if its some other client's
plan id is used. If this brings clarity we can be explicit about this
expectation in the spec.
There are already rest endpoints such as
/v1/{prefix}/namespaces/{namespace}/tables/{table}/plan/{plan-id},
where the client can check status of the plan by passing in the plan-id, if
the plan-id is not something the client is authorized to access, the server
is expected to throw 403 is my understanding
Best,
Prashant Singh
On Fri, Nov 14, 2025 at 12:04 AM Steven Wu <[email protected]> wrote:
> I assume the `planId` should be treated as a shared secret btw client and
> server. If client A gets hold of the planId for another client B, client A
> can access data files generated/targeted for client B.
>
> Or the server is expected to validate that the planId was meant for the
> correct client?
>
> On Tue, Nov 11, 2025 at 9:55 PM Jean-Baptiste Onofré <[email protected]>
> wrote:
>
>> +1
>>
>> It sounds good to me as it can help the server with context.
>>
>> Regards
>> JB
>>
>> On Fri, Nov 7, 2025 at 7:49 AM Eduard Tudenhöfner
>> <[email protected]> wrote:
>> >
>> > Hey everyone,
>> >
>> > I'm proposing to add the planId from server-side scan planning as a
>> query param to the /credentials endpoint.
>> > This is needed so that the server has some additional context when
>> credentials are refreshed with server-side scan planning.
>> >
>> > The proposed OpenAPI changes can be seen in #14519.
>> >
>> > Looking forward to your thoughts and feedback.
>> >
>> > Thanks,
>> > Eduard
>>
>
