*Idpy meeting 19 December 2023* Attendees: Shayna, Ivan, Roland, Matthew E. 0 - Agenda bash 1 - Project review a. General - b. OIDC libraries - https://github.com/IdentityPython (idpy-oidc, JWTConnect-Python-CryptoJWT, etc) - idpyoidc 3.0.0 released - openid federation implementation - Roland has openid4v (wallets) - assumed openidconnect at base but it is oauth. - Reminder that client registration information is not well-documented. - SATOSA container generates xml so that a newbie can get it going; intent is to have a docker compose project that can stand up an oidc environment and showcases all different integrations - Roland has SATOSA OP frontend that is sort of based on Giusppe's work, but partly new. He has the federation support. Didn't want to be dependent on MongoDb, has persistence layers with store/fetch. Ideally there is a function to register an OP (independent of backend). - Ivan acknowledges that registration process is not well documented and assumes pre-existing knowledge. Also does not have good examples. He has not really used the dynamic registration, but has used static registration with the database for client data. He has used different authentication methods for the clients: basic auth or client secret post. Beyond that things get strange. Basic use cases are there and some advanced ones, but some may be missing. The problem is there is not just one level of documentation - are you a user, a developer? Roland has worked hard on base documentation for idpyoidc at https://idpy-oidc.readthedocs.io/ but it needs to be updated. This is for the library. The front end is one layer above and we could use documentation for that as well. - openid federation adds a whole different layer to this. Clients no longer register, they just become members of the federation. c. Satosa - https://github.com/IdentityPython/SATOSA - Considering how to expose metadata in openid federation format - Some work required before making a new release - Need to pull in Roland's PR separating pyoidc and pysaml2 from core - Looking at PR on plugin for getting session info from SAML entities - but the project tries to keep plugins protocol agnostic (this is clearly SAML specific). - This brings up: how do you map from oidc to SAML? Right now claims and attributes are mapped; scopes are there but not really reflected in internal data. Acr claim and amz claim are also not reflected in internal data. Need a document on how to map between the protocols and derive the internal data. This is needed if we want to extend the core with more protocols. - jwt token from saml transaction (there is a spec) d. pySAML2 - https://github.com/IdentityPython/pysaml2 e. Any other project (pyFF, djangosaml2, pyMDOC-CBOR, etc) - Matthew working on getting SeamlessAccess pieces into one release-ready container. If you have feet in both oidc and SAML worlds, how do you take advantage of scalable federations in both with a consistent user experience? He's been coming up with ideas mostly surrounding mirroring in SATOSA, to expose oidc as SAML. It is tricky, treating the oidc entities the same as saml identities. - Discussion of how to handle this; pictures attached. 2 - AOB - Next meeting 9 January and then every 2 weeks after that