None

2) These all are easy pull requests that can be easily merged after a fast revision, b) d) and e) are pure bugfixes: a) ldap_store refactor: https://github.com/IdentityPython/SATOSA/pull/252 <https://github.com/IdentityPython/SATOSA/pull/252> Will merge. This is mainly a discussion between Pepe and Scott. b) Cookie state exception fix/workaround: https://github.com/IdentityPython/SATOSA/pull/250 <https://github.com/IdentityPython/SATOSA/pull/250> Will merge. c) multiple user_id: https://github.com/IdentityPython/SATOSA/pull/222 <https://github.com/IdentityPython/SATOSA/pull/222> Could also do this via a microservice; may have one that already does this. Ivan will let Pepe know; having an example in this PR before closing would be helpful. d) sign_alg/digest_alg policy fix: https://github.com/IdentityPython/SATOSA/pull/216 <https://github.com/IdentityPython/SATOSA/pull/216> There is a similar PR on pySAML2 about introducing these options. (It was easier in Satosa.) Could map this to different configuration options to the backends, but would then need to map everything. It’s still a question on how to handle the different configurations between pySAML2 and Satosa. Will merge this now, and when we have support in pySAML2 code, we can drop this from Satosa. Will still need to work on generalizing this. e) selectagle dig/sign algs in backends: https://github.com/IdentityPython/SATOSA/pull/214 <https://github.com/IdentityPython/SATOSA/pull/214> The previous one (216) is a bug fix; this one is a proposed change. Still, see above as it still applies 3) The possibility to select the backend to use in base of the entity Id used for authentication. Proof of concept here: https://github.com/IdentityPython/SATOSA/pull/220 <https://github.com/IdentityPython/SATOSA/pull/220>. I cannot do a separate microservice because this implementation needs a little but easy implementation into SATOSA core, I tried to code it as easy to read as possible. This extends custom routing. Ivan will look at it. 2. Hackathon planning - https://wiki.refeds.org/pages/viewpage.action?pageId=44959235 <https://wiki.refeds.org/pages/viewpage.action?pageId=44959235> Note that you have to register (even if you’re a speaker). What do people need to get started? Suggest setting up a VM for Satosa so that people have a ready-made environment. Can set up a small image with everything ready and packed in, with no other setup. Will put it in the repository as an image. Will reuse this for other purposes (including future Hackathon). In the past, we’ve talked about having images that demonstrate different use cases; can use this for small demos. Action item for Ivan; will try to have that this week For the OIDC Federation table - they need to have read the specification and understood it. There will be at least three people at this table, including two Java programmers. When they have something running, will start doing interop testing; Roland will have entities available for them to talk to to test their code. The SimpleSAMLphp programmer will also be there, but he may be at another table. The developers will have their own environment with them on their laptops. Need to ask for white boards. Would be good if the EIDAS people would be there. John suggests looking at using this https://github.com/sitya/samlidp <https://github.com/sitya/samlidp> as a fast sp/idp deployment; might not be the best fit. Christos points out that they have an instance that might allow people to spawn SPs there. But if you want the developer the experience to deploy the IdP, then need to do more. Probably don’t need the IdP to do anything special; need to focus on developing the proxy and microservices. Pepe: as SP I used this for my tests: https://github.com/peppelinux/Django-Identity/tree/master/djangosaml2_sp/dj… <https://github.com/peppelinux/Django-Identity/tree/master/djangosaml2_sp/djangosaml2_sp> and pysaml2 idp I used uniAuth ( https://github.com/UniversitaDellaCalabria/uniAuth <https://github.com/UniversitaDellaCalabria/uniAuth>) If anyone else has more ideas on what they’d like to see during the Hackathon, please post to the list or send to Ivan 3. AOB Next call: 3 September 2019. Will discuss status of Hackathon prep, OIDC libraries (if Roland is available), any pyFF updates (if Scott/Leif are available), and items from the mailing list.