Bi-directional and Implicit Profile

Issue #8 new
Phil Hunt created an issue

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)

  1. Dick Hardt

    This was adjusted in the last specification. There is a requirement that the control plane access control is RFC 6950.

  2. Phil Hunt 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.

  3. Marius Scurtescu

    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.

  4. Marius Scurtescu

    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."?

  5. Marius Scurtescu

    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?

  6. Log in to comment