Attendees: Matthew, Hannah Sebuliba, Ivan, John P, Leif, Roland, Giuseppe Agenda: 0 - Agenda bash 1 - GitHub review    a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP, JWTConnect-Python-CryptoJWT, etc) Roland is currently working with SQL Alchemy some of the code base, starting with CryptoJWT, and will be working his way up the stack. A request has come in to make this more a general interface that will support more databases. Next problem is around messages and message instances - according to the spec, you should always expect attributes you don’t know about and you should accept them. SQL Alchemy requires you know all the attributes. What about the device flow? It’s not hard to do; has done the client part, but no the server part.    b. Satosa - https://github.com/IdentityPython/SATOSA More on error handling (see Giuseppe’s PRs, mentioned in Slack) This needs to be more modular and separate from the core code. What happens is, when Satosa sees a request, it parses and figures out the right thing to do. When things fail or an exception is raised, then the exception is logged or it is unhandled and things crash (though we have a global exception handler that should prevent the latter). Instead of logging and resuming, want to delegate the action to another function. This function is something that the user needs to provide. We can have a default behavior, but the user needs to be able to override that. What Giuseppe has done (and eduTEAMS) is to catch the exception and redirect there. But we may want to do more than redirect. So we need to have the flexibility to define both a default and a config option. Could implement the Error Handling WG functionality as an option and let users pick what they want. We could also use this to communicate to external services so they can render nice error pages. What information do we give to this function to convey the right information to the external service? How do we collect the context and pass it in a unified interface? Giuseppe suggests just title, message, description. Otherwise, still need to get to the refactoring of how we handle paths. We have regularly encountered a problem where pySAML2 converts everything into a friendly name, and this has impact on Satosa. When an SP has requested attributes in its metadata, they don’t match to what Satosa has internally (canonical name vs friendly name). This will impact both internal and external attributes. We’ll eventually make these changes mandatory. Roland is looking into SQL Alchemy. We’ve gotten away from having state in the proxy, but we do need state for the OIDC front end. If we need to keep state at some point, we should probably be doing it through SQL Alchemy. We should look at what happens with MongoDB and Alchemy to make sure everything is supported. If it isn’t, we need a migration path. Is the data that you want to store inherently relational? If not we don’t need a relational database. Would an API be a better approach, implementing a simple state API? Unsure what would be best as we don’t have the actual use cases at hand. Ivan and Roland both will consider this further.    c. pySAML2 - https://github.com/IdentityPython/pysaml2 Will get to this on our next call.    d. pyFF - https://github.com/IdentityPython/pyFF pyFF and the accept header (Scott) Two related issues - if you have a compliant client doing MDQ, then it will send an accept header of application/SAML metadata + XML. If it is going to be a compliant response, then you have to get a single entity descriptor as a wrapper. Scott was getting a multiple entities descriptor, which was rejected. This may just be a configuration problem. Some updates need to be made to the documentation . Related: pyFF tries to be helpful in that it wants to be generous in what it accepts, so when you send in a different header, it wants to do the right thing. In addition, it lets you append to the entity ID a type, like a .xml to help guide pyFF re: what you want in return. The problem is, there are a few SAML entities in eduGAIN whose entityID ends in “.xml” and so pyFF decides to drop the .xml. How will pyFF decide on the content type if you remove this functionality? This can be part of the pipeline configuration. pyFF is not just an MDQ service - it’s to handle whatever you want to do with metadata. It would be nice if the docker file for pyFF could take a build argument, and when it saw that, what you’d get was a preconfigured docker image that knows how to one thing: be an eduGAIN MDQ server that’s compliant. Leif will work on that. WRT the JSON part, we can request a json representation, but it’s not a 1:1 list of what’s there; there is no json profile for the metadata. This profile was defined only unofficially twice: in Discojuice and in Thiss.io. Do we want a complete json representation of the metadata? Is there a use case for it? There is a use case around defining the UI elements. We still don’t do i18n properly; definitely more to be done there. It’s worth considering how to start a discussion about a JSON UX metadata format. Who should be involved in that? 3 - AOB