fivetran-arunsuri commented on PR #2197: URL: https://github.com/apache/polaris/pull/2197#issuecomment-3243030488
@flyrain Pasting what we discussed in DM around the reset vs rotate: I see your point about client_id semantics and the flexibility of reusing the rotate endpoint. That said, I’d still lean towards keeping a separate reset API, mainly for clarity of intent from a client perspective: - rotate suggests replacing credentials while keeping the same client identity, whereas reset communicates a stronger action (e.g., provisioning a completely fresh set). - users often expect reset when dealing with credentials (similar to password reset vs password rotate), so the explicit endpoint helps reduce confusion. - Future flexibility: if Polaris later wants to evolve different behaviors (e.g., stricter validation or revoking old client IDs), having both endpoints gives us that room without introducing breaking changes. - On top of that, the current implementation is limited to the root principal. rotate doesn’t work with the root principal (only with its own creds), so reset is the right fit here. It also provides a way to reset forgotten credentials for a particular principal without touching the existing implementation. Finally, this direction was already discussed and agreed in the Dev email thread to support a separate endpoint, so keeping both aligns with that decision—rather than using the same API as createPrincipal by passing custom creds, as I initially proposed. Would you be open to keeping both endpoints? Can we go ahead with the PR? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@polaris.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
