Closed gffletch closed 5 months ago
Some thoughts:
azd
claim. I can see in some instances that the requester has more control over what goes into the claim, and in some cases, the TraT service has more control.azd
object, because it is signing the TraT.Regarding (1) -- I think we still need a way for the client to pass in data to the TTS that it can use to generate the values. Even if how all that works is out of scope for the specificatio.
Regarding (2) and (3) -- I'm ok with leaving the rules out of scope for the specification. The TTS will be authoritative for the resulting azd
object and whether it should be protected in some way or not.
I am curious to hear from others as to their thoughts.
Suggestion to rename authz_details
to request_details
and then add a processing rule to the effect of... "The TTS SHOULD propagate the data from the request_details
object into claims in the azd
object as authorized by the TTS authorization policy for the requesting client"
This has been fixed AFAIK. Please reopen the issue if it hasn't been fixed by George's PR.
PR #57 raised a number of issues around processing of authorization details
azd
claims be visible to all workloads? or should they be restricted to a subset of workloads?azd
object