*Attendees: Ivan, Shayna, Giuseppe0 - Agenda bash1 - Project review a. GeneralGiuesppe discussed this wallet project for onboarding and trust anchor demo: - https://github.com/italia/spid-cie-oidc-django/tree/main/examples/wallet_tr… <https://github.com/italia/spid-cie-oidc-django/tree/main/examples/wallet_trust_anchor>This is to be used in Italy with the OIDC federation for the two national identity systems, SPID and CIE. This includes a quick tutorial on how to get an entity onboarded, and also how to use customizable templates. The good news in this project is that using federation for the wallets doesn’t break anything with the federation - federation works as is.Giuseppe also discussed this project: https://github.com/italia/eudi-wallet-it-python/tree/dev <https://github.com/italia/eudi-wallet-it-python/tree/dev>SATOSA is already being used for the interop requirements between the vanilla saml2 implementation and the implementation profiles pertaining to SPID and CIE. They have decided to implement a SATOSA backend on top of this to support the implementation profile they have published : https://italia.github.io/eudi-wallet-it-docs/versione-corrente/en/ <https://italia.github.io/eudi-wallet-it-docs/versione-corrente/en/>. In the Relying Party Solutions section they give guidance about implementation profiles and also some normative examples. This works with any SATOSA, although they are forced to work with Giuseppe’s fork in Italy regarding pysaml2 for the namespaces - since in Italy the namespaces are normative.Ivan suggested having a more focused meeting between SUNET and Giuseppe about these projects.Giuseppe and Roland have been talking about the requirements in our community to have a credential issue in python. Is there something on the way in the form of SimpleSAML frontend or django? Ivan says they are in discussion with organizations like https://github.com/sicpa-dlab <https://github.com/sicpa-dlab/> to be aligned and move forward together. They have a big system with many interfaces. The idea is to be aligned on the APIs. They have some things in python re: credentials that we can use and then they will probably be using the MDOC that Giuseppe has created. Ivan has been thinking about a framework - using django is not a bad idea. It is much more mature than other choices. He has been thinking about using django in general as a base for SATOSA. Giuseppe talked about developing djangosaml2 - he put out the original release and it has grown to v1.7.0 ( https://github.com/IdentityPython/djangosaml2/releases/tag/v1.7.0 <https://github.com/IdentityPython/djangosaml2/releases/tag/v1.7.0>) with little effort on his part. He credits django with increasing productivity for the community working on it. Ivan says the hard part is compatibility with what it is already there. <https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/main/arf.md> b. OIDC libraries - https://github.com/IdentityPython <https://github.com/IdentityPython> (idpy-oidc, JWTConnect-Python-CryptoJWT, etc)https://github.com/IdentityPython/idpy-oidc/pull/72 <https://github.com/IdentityPython/idpy-oidc/pull/72>Refers to how OIDC checks whether a call to a userinfo endpoint is correct/valid. In order to call the userinfo endpoint, you need to have an access token that has at least the openid scope. If the access token is valid (meaning it hasn’t expired/hasn’t been revoked and has the right scope), you can invoke the userinfo endpoint and get a response. Idpy-oidc checks an additional thing - the date the authentication took place, which also has an expiration time. This should not be done - the access to the userinfo should be based only on the access token. This additional check breaks certain flows and is against the spec. This PR removes that additional check. Should talk more with Roland to get his thoughts. He and Giuseppe have been added as reviewers. c. Satosa - https://github.com/IdentityPython/SATOSA <https://github.com/IdentityPython/SATOSA>Ivan wants to make a new release. Changes were discussed at last meeting. A new backend was introduced that depends on idpy-oidc. The next step (after release) is to make the saml parts optional (it’s possible Roland has already done this work). Some classes will need to be moved. This can be problematic - we need to make sure there are compatibility fallbacks when we move the base classes elsewhere. Hopefully no one is using those classes directly. There are also some smaller changes to be merged. They will be released after the release with the oidc changes.https://github.com/IdentityPython/SATOSA/pull/441 <https://github.com/IdentityPython/SATOSA/pull/441> - Ivan has not had time to look at this yethttps://github.com/IdentityPython/SATOSA/pull/435 <https://github.com/IdentityPython/SATOSA/pull/435> - complex MR about addtng types and type information. This needs some more thought before being pulled in. https://github.com/IdentityPython/SATOSA/pull/431 <https://github.com/IdentityPython/SATOSA/pull/431> - from Hannah about logout. We should have a meeting to discuss this one alone. This introduces a need for server side state. We will have to use something like Redis and bind proper identifiers to the logout flow. Once we have that we can do the same for the communication flows etc. Guiseppe brought up that SATOSA already has mongoDB as a dependency even just for unit tests. Giuseppes’s frontend (https://github.com/UniversitaDellaCalabria/SATOSA-oidcop <https://github.com/UniversitaDellaCalabria/SATOSA-oidcop>) was migrated to idpy 3 weeks ago and uses mongoDB in order to reuse an existing requirement. There are some concerns about mongoDB’s limitations in terms of license - it can be expensive. Its config is complicated. Redis seems simpler. But we don’t have to choose - we can have an API to work with both, the user chooses. There is some work around an API in idpy-oidc that could be reused for this. d. pySAML2 - https://github.com/IdentityPython/ <https://github.com/IdentityPython/>. Pysaml2There are some MRs and PRs to look at but Ivan hasn’t had time to look at them e. Any other project (pyFF, djangosaml2, pyMDOC-CBOR, etc)No updates.2 - AOB Giuseppe asked are there any resources or experience related to our community about the implementation of second factor authentication as a SATOSA backend.Ivan says Peter from DASI has done something around this and others have also - Ivan thinks the implementations use a microservice to contact a third party service and have a flow with the second factor. There is an effort to address this. The problem comes from licensing - AGPL licenses.Shayna adds this link to a presentation done at Internet2 TechEx 2022 by Matthew E and Benn O pertaining to using COmanage Registry, SATOSA, and Privacy Idea to implement an MFA solution for access to SPs. https://internet2.edu/wp-content/uploads/2022/12/techex22-info-sec-dynamic-… <https://internet2.edu/wp-content/uploads/2022/12/techex22-info-sec-dynamic-mfa-economou-oshrin.pdf>When are people available for the next meeting? Ivan is away the week before the next meeting, so not much in terms of updates will be available; Guiseppe has a deadline so will probably not be there.Thanks, Shayna*