...
- Do you have or expect to have a mobile application in your organization that could benefit from OIDC's support to "native apps"? Example scenario: "We have a mobile app that, upon successful authentication via LDAP, gives access to our internal VoIP system, allowing performing voice calls to the physical devices located at the different offices around the campus. Replacing this organization-only authentication with a federated one, visitors would be able to to call their hosts or any other administrative destination with no cost or hassle".
- What about server to server communication ? As easily
as we can build a OIDC federation we can build a OAuth2 federation which opens up some interesting new avenues. - One can imaging different federation operators taking different interest in the state of the federation. What kind of functionality would an involved federation operator need ?
- What do others think about allowing 'anyone' to use their own APIs through the OIDC federation? ("Authorisation-Server-as-a-Service")
- It seems like OIDC significantly lowers the bar for integrating services with federations, which is for example noticed by the research community (at least in Australia
). But what does this mean for federation policies, contracts, agreements, etc.? Will there be 2 separate federations with different technologies (SAML vs. OIDC) and different policy sets? - <Your topic to discuss goes here>
...