(Chris Phillips)
The idea of the session is to get a glimpse into the OID foundation and to get feedback on what is needed to be added: Gathering new use cases, that will help improve the process itself.
The idea is to gather these use cases and bring information to the community about what is happening with this additional protocol and the roadmap ahead in terms of the next 6-12 or 18 months. It is critically important for the immediate future of this project to be successful.
As opposed to what we are used to in most communities, OID foundation has a different governance of things, you need to become a member to have a vote to pass certain proposals.
Profile covers things like schema, attributes needed in the R&E and multi-level federation.
In the OIDC world there is a scaling challenge, how to apply techniques to have one signing key authorize in a hierarchical nature.
Mischa: Current way of getting clients connect deals with dynamic registration - doesn’t work in our infrastructures. We need an authentication that trusts without knowing the other party. Most options right now are not scalable.
There are two working groups: 1. R&E group that is developing a profile for OIDC with specific requirements for security 2. AB connect working group where the federation is done.
OpenID will emerge soon into various different scenarios. Examples: federation of two factor tokens, federation of openID apps etc.
R&E working group serves the purpose of developing a set of profiles for the OIDC specifications to ease the adoption of OIDC in the R&E sector. The process considers existing practices and also current international standards.
From the main federation key holder down to the federation operator in the region down to a specific institution, allowed to create keys – this hierarchy is what it means to be in a federation. What it means for us is that we won’t be adding partners to the federation lower levels. This makes it much easier to distribute trust essentially!
We have now entity records, records of SP and ID providers. SIRTFI decorates the record of those entities and it means something different – if you behave certain way or expect the ID providers to grant you certain attributes.
If a relying party says they have an API that offers material to a certain community, if they would use OIDC being part of the R&E working group, as soon as the profile is satisfactory, the OIDC takes care of the trust part.
Any organization can use substantially off-the-shelf OIDC components and if the keys are assigned properly – it should work as expected.
Why do we need OIDC federation in the first place? If you use OIDC only, there is no way to know the trustworthiness of the other party. It needs to be a bilateral connection.
Is the conversation about the conversion of this technology or developing something new entirely? In OIDC there are off the shelf libraries ready to provide the service, but they also constrict people from using it outside its certain scope.
SIRTFI is not only a SAML thing – its protocol independent. SAML is a way to express our policies.
Matthew: I would rather have a purely generic external authentication interface. Remote user adds in a variable for authentication of groups and simple environment variables, system administrator defined variables. That should be then the application level authentication tool. If we try to encourage application specific implementation of tech, odds are they will not get it right.
Mischa: then you are just shifting the problem from one responsible to the other one.
Matthew: Application developers maintaining users and authenticating it inside the application – why worry so much about the protocol and not the information conveyed itself? Why not simply go with SGI instead of all the options of LDAP, SAML, and maybe in 5 years OIDC?
The problem Is not the misunderstanding anymore, is that people will not apply it.
Chris: The information architecture that these applications need is one of the elements in the OIDC – the way to get there – we are following here, following Google, Microsoft etc. who have already implemented OIDC.
Suggested Use case:
Developing services needs to define what kind of information they are expecting to receive, without need to know how it will come. If you want to facilitate provisioning of services to a wide science community in all possible ways – lot of these services will work in processes and workflows that combined can provide much better info and service. One of the requirements is how to federate them when wanting to enlarge the community that will access them. With the current setup of federations, I need to think ab machine 2 machine, I want to recognize user entering in an entry point and from there to start the process. Services can be everywhere in the world, there has to be an agreement on attributes, what they mean and how they are named. It needs to be homogenous.
OAuth as a solution: Protocol translation via the proxy & delegations via OAuth tokens.
Technology is just the vehicle – OIDC keeps it low level as SAML beforehand. It pushes for common dictionary, common multi-lateral trust models.
Enhancing the existing protocol - 20% of the effort Integration and operationalizing - is it 25% or is it all of it?
