Rahmat Hidayat

my rough thought for now is, we can introduce `type` field in the approval step configuration. If the approach for this is to fetch to external service, we can set...

pardon me, I just realized that we already have `strategy` field with possible values `auto` and `manual`, we can simply introduce `http` for this 😁

@singhvikash11 we need to define a contract for the http api, can you help with that?

my proposal for this: ```yaml # policy id: my-policy steps: - name: owner-approval strategy: manual approvers: - $appeal.resource.details.owner - name: external-approval strategy: auto http: url: http://example.com/approval/$appeal.account_id headers: X-Foo-Bar: baz authorization:...

@ravisuhag because http fetch approval is essentially an automatic approval that doesn't require human approval

@mabdh yes, that's the case for permanent access

@bsushmith @Chief-Rishab I was thinking that guardian can have a job that periodically checks the invitation status to the provider and set the access status to `active` or `canceled` accordingly...

in order to rollout this `access` entity while still maintaining the backward compatibility for the client (frontend), we need to have two separate releases/versions: ### Release 1 - introduce `access`...

@mabdh the releases I mentioned are specific for guardian (backend), updating the client going to be a separate task. But still, release1, update client, and release2 had to be done...

@mabdh the client (frontend) now is managed in different project/repo anyway, so the requirement for guardian is only to have two separate releases/versions with requirements I mentioned above. This strategy...