Bi-directional and Implicit Profile
The profile makes a lot of assumptions that only OIDC OP's are issuing events.
The profile does not clearly discuss how RP's issue reverse events.
The profile does not discuss how implicit federation works where no OIDC relationship exists.
Comments (6)
-
-
reporter Where is that requirement? The point here is to debate that requirement.
SMTP IDPs and RPs do not have OAuth services. So no standard way to issue tokens (let alone no standard way to obtain them). This will end up being a significant amount of manual configuration.
If manual configuration there is little value in having a control plane standard that has to be custom coded just for a sub-set of RISC cases.
-
See response to Issue #7
-
Phil, can you please point in the profile where this is the case: "The profile makes a lot of assumptions that only OIDC OP's are issuing events."?
I agree that this should not be the case.
-
Phil, you just argued (and I agreed) that discussion should not be centered on OPs and RPs, then why is this needed: "The profile does not clearly discuss how RP's issue reverse events."?
-
Phil, regarding "The profile does not discuss how implicit federation works where no OIDC relationship exists."
The profile is defining the add/remove subject API. What else is needed for implicit federation? What exactly is tied to OIDC?
- Log in to comment
This was adjusted in the last specification. There is a requirement that the control plane access control is RFC 6950.