collado-mike commented on code in PR #1353:
URL: https://github.com/apache/polaris/pull/1353#discussion_r2070637045
##########
spec/polaris-management-service.yml:
##########
@@ -1105,6 +1105,30 @@ components:
required:
- name
+ Principal:
+ description: A Polaris principal.
+ type: object
+ allOf:
+ - $ref: '#/components/schemas/BasePrincipal'
+ - type: object
+ properties:
+ clientId:
+ type: string
+ description: The output-only OAuth clientId associated with this
principal if applicable
+
+ FederatedPrincipal:
+ description: A federated Polaris principal.
+ type: object
+ allOf:
+ - $ref: '#/components/schemas/BasePrincipal'
+ - type: object
+ properties:
+ federated:
Review Comment:
The intention in this change to the spec is to clarify in the spec what can
be sent to the modification APIs (create/update) and what can be returned in
the read APIs. Federated principals can be returned, but can't be created or
updated. I proposed making this change in response to your comments on the
previous revision -
https://github.com/apache/polaris/pull/1353#discussion_r2045082533
TBH, I would have preferred not creating separate types on the backend (the
original revision simply added a `federated` field), but this was the only way
I could force the spec to treat the two types differently.
The `federated` type has to be present in order for clients to be able to
distinguish between federated and non-federated principals. `type` doesn't
translate in JSON - only the presence and values of the fields in the response.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]