*Idpy meeting 11 June 2024* Attendees: Johan L, Shayna, Ivan 0 - Agenda bash 1 - Project review a. General - b. OIDC libraries - https://github.com/IdentityPython (idpy-oidc, JWTConnect-Python-CryptoJWT, etc) - Roland has opened an PR - it fails one of the tests - https://github.com/IdentityPython/idpy-oidc/pull/104 - https://github.com/IdentityPython/idpy-oidc/issues/106 - A claim that is expected to be returned is not coming back anymore. - Not understanding why this is happening - Is the test actually a requirement of the spec, or just something the test assumed would be there? - This PR addressed changes required to align with the PAR (Pull Authorization request) rfc - RAR (Rich Authorization request) allows you to define more things happening during the authorization phase - Have pinged Roland but haven't heard back. If Ivan has time he can also look into this. - New PR - https://github.com/IdentityPython/idpy-oidc/pull/107 - Allowing variable ports for native oidc clients or RPs when the redirect uri is the literal localhost - the actual IP ( IPv4 127.0.0.1 or IPv6 ::1 / 0:0:0:0:0:0:0:1) - spec says native clients, when they start an authorization flow, they do this through the loopback interface and bind to 127.0.0.1 / ::1 and can use any port available. The port is decided directly by the platform and the client does not have control of that. - requests are forwarded to the auth server with the port assigned by the system - This PR allows variable port exception for native clients - introduces checks around redirect uris - they become part of the location header - they are URLs and not uris. They can have other schemes. The python library doesn't do certain validations so they have to be done manually around this uri (which is a URL) - scheme: path/domain/valid port. - This PR bound to http URLs - There is further work to be done to filter out certain schemes for the redirect uri that wouldn't make sense in this case and could be dangerous. Ivan will make an issue for this. c. Satosa - https://github.com/IdentityPython/SATOSA - Ivan is supposed to create a new release-hasn't done yet. - Matthew needs to update image around missing SAMLtest ID - he's probably waiting for Ivan's new release - updates on pyop to start deprecating- https://github.com/IdentityPython/pyop/pull/55 - https://github.com/IdentityPython/SATOSA/issues/445 - pyop provides interfaces that are useful also for SATOSA. Support was added in pyop for stateless flows - all the state kept in tokens. There are limitations to this - there is a size limit - but it does allow no need for a db and keeping state. Another drawback is you can't tell when token has been revoked. - when the code was introduced it broke another part, having to do with the claims from the user info endpoint. - Fix is to bring back the old flow and make an exception when in the stateless mode. - this MR will be merged and new pyop released but really pyop should be deprecated. There should be amendments to the Readme pushing people toward idpy-oidc. Already have a SATOSA backend using idpy-oidc. Don't have support for a frontend using idpy-oidc. There is the work Giuseppe has done which we already point to. We are not removing pyop but saying that the focus is somewhere else. d. pySAML2 - https://github.com/IdentityPython/pysaml2 - Johan's PR - https://github.com/IdentityPython/pysaml2/pull/964 - Big divide in security domain - make things configurable - this is what xml dsig/encryption is about - but as you interoperate with others it makes updating difficult. - OR everything should be pinned down to very specific things - no random lengths of keys, no random types of keys, no random algorithms etc. Everything is specified and there is only one way to do things. If you pick the right things, you are future-proof. This is what signal is about. - Add xenc schema 11 to code base. - pysaml2 added support for xmlsec binary - frederik's MR about typing is related to this - https://github.com/IdentityPython/pysaml2/pull/897 - Ivan will merge Johan's PR (964 - need to also check whether anything is needed to support newer version of xmlsec1) and make a release, then merge PR 897 to unblock Johan, then get back to 961 adding support for xmlsec module https://github.com/IdentityPython/pysaml2/pull/961 - Also need to make sure xmlsec module doesn't need lxml - a few annoying things: xmlsec module defines its own types for handling keys and certificates, then there is another type we define based on pyOpenSSL, then there is another type from pyca/cryptography - just keep having to convert from one type to another. - xmlsec1 - C libraries - had to provide specific constraints to restrict xmlsec from going out to the web to fetch keys or metadata or other interfaces to do calculations. Ivan is pretty sure xmlsec module is doing the same thing, - also would use signing key from within the SAML response itself instead of key extracted from the metadata - We have tests for the binary - make sure they also work with xmlsec module, then limit functions in code - e. Any other project (pyFF, djangosaml2, pyMDOC-CBOR, etc) - work on pyff around supporting trustinfo elements - spec stems from seamlessaccess - they indicate certain IdPs are preferred over the rest - you can say you only want to select from those - they can be highlighted or ranked first, for example. There can be complex rules indicating preference of sets based on assertion authorities or other things. 2 - AOB - Ivan will be away 25 June. Will check with Roland for his availability and determine if meeting will happen.