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]

Reply via email to