Attendees: Johan, Ivan, Heather, John, Leif, Christos, Scott Notes: 1 - GitHub review    a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP, JWTConnect-Python-CryptoJWT, etc) Some activity between Jakob and Roland on the    b. Satosa - https://github.com/IdentityPython/SATOSA Ivan has been creating a login helper for Satosa, getting rid of boiler plate around the logging, and have an internal logger that will do things more sensibly Most of this is ready, but he’s also looking at another library which might be more useful for internal logging. Stay tuned! Scott made an improvement to the LDAP attribute store microservice. He was previously filtering for specific SP configuration, but has switched that to filter for any kind of entity. This is already something most other microservices also do. Ivan is considering whether the core Satosa should do this as well . Scott also added a new merge request. (See email to the dev list). Proxy has many different entry points. One of the entry points is the response from the discovery service. We can actually send a response from the discovery service directly to the proxy without requesting authentication. This won’t work unless someone makes some special changes. Scott proposed a change that would enable the to be turned on or off. Ivan thinks we perhaps shouldn’t allow this behavior at all; there must be a target SP and if there isn’t one, we stop the process. Next on Ivan’s list is redoing the way we handle paths. Right now, we have a base (a domain) and we mandate that all backends/frontends operate below that base URI. We cannot have a domain that also contains a path. The changes will allow this to happen (paths in the base URI), which will in turn allow us to do things like integrate the new OIDC front end while still running the old OIDC front end and differentiating between the two. Will also be introducing the new config for the metadata end point. eduTEAMS: how exceptions are handled - there is a global exception catcher, but it can raise an “unknown error”. Want to have an error URL; if that’s defined, we should redirect the user to that error page. That error page will show an informational message. This could work well with the outputs of the REFEDS Error Handling WG (note that the community consultation process for that doc is expected to start later today).    c. pySAML2 - https://github.com/IdentityPython/pysaml2 On a previous call, we talked about the GCM encryption family. Is still looking into that. Some discussion about supporting libxml, though we would need some wrapping for it. This looks like a good direction, but the transition will not be fast. Will want to split the network operations from other components. Getting the algorithms in metadata an d prohibiting specific algorithms is of higher priority. We want to verify that a signed request has been signed with a cert we know about; Roland has said this kind of verification is an experiment. It shouldn’t be part of the library.    d. pyFF - https://github.com/IdentityPython/pyFF Focused more on the Thiss.io library. What’s on the roadmap right now is figuring out what to do with Scott’s PR around path naming. Also still working on moving to 2.0 and excising all the front end bits. Trying to figure out how to package of pyFF, or at least a frontend script, that will allow you to start components the way pyFF is put together today. eduTEAMS is using the latest code where front end is split from the back end, and what they found was they needed a guide that offered the order of what they needed to do to set the pieces up. Need more documentation, and this is probably more important than backwards compatibility. 3 - AOB Also in eduTEAMS, we have a proxy that talks to OIDC and SAML entities. Internally, we need a representation fo the metadata of those entities. If we have an MDQ, then the metadata is already there - we can get them from the file system or cached. For OIDC entities, though, that doesn’t exist. Would like to have a way to find out the metadata of OIDC entities and represent them in a common way in the proxies so they can be displayed somewhere (e.g., consent service). If you don’t need any of the cryptobits, then you can extract the metadata and turn it into Discojuice-formated JSON and dump it into a discovery service. pyFF is a SAML only thing; in SeamlessAccess, pyFF is used to aggregate and format metadata into JSON and dump it into a central MDQ. Sounds like they need multiple processors that will dump into a common repository. This will become important when we have OIDC federations, though it depends on how OIDC federations will finally look like. But whether pyFF will fit that model is still an open question.