*Idpy meeting 10 October 2023*
Attendees: Johan, Matthew, Hannah, Shayna
0 - Agenda bash
1 - Project review
a. General -
b. OIDC libraries - https://github.com/IdentityPython (idpy-oidc,
JWTConnect-Python-CryptoJWT, etc)
c. Satosa - https://github.com/IdentityPython/SATOSA
- Everyone who had attended the SATOSA PR-431 SLO review felt it went
well. Matthew E. was encouraged to see that limitations to pysaml2 were
acknowledged. Shayna will reach out to Ali H. for updates on when he
has/will push his changes so he and Hannah S. can collaborate on a vision
for single logout.
- Matthew E. is working on SATOSA container - he knows the current one
is out of date. Ivan merged some changes on pyop and Matthew has a better
understanding of the newer oidc libraries, so he wants to come up with a
working test config for oidc and include it into the sample configuration
of the container. He is not sure where to find a test OP.
d. pySAML2 - https://github.com/IdentityPython/pysaml2
e. Any other project (pyFF, djangosaml2, pyMDOC-CBOR, etc)
2 - AOB
- Next meeting is 24 October 2023.
On 2023-10-05 15:24, Heather Flanagan wrote:
> I'm a little uncomfortable accepting a project sight-unseen. Are you
> willing to make sure it conforms to idpy's code guidelines in a
> reasonable amount of time if/when it's accepted under the project umbrella?
>
Absolutely. We may just publish it under BSD-2 under the wwwallet.org
organization on github and then talk about its future!
Cheers Leif
A clarification: there is very little python today in the project. We
are working on this but I want to be clear that this is a borderline for
idpy because of this.
Cheers Leif
On 2023-10-04 23:23, Giuseppe De Marco wrote:
> Very interesting and useful!
>
> Is there any GitHub/bitbucket/gitlab public repository to have a quick
> dive in its sources?
We would like to hold off on publishing the source until we know where
it should land...
>
> I assume that It represents an entire wallet solution, composed by
> wallet provider and wallet app, and that the wallet app Is a web based
> app, not intender for any appstore
Correct.
>
> Congrats, It looks good
>
>
>
> Il mer 4 ott 2023, 22:09 Leif Johansson <leifj(a)sunet.se
> <mailto:leifj@sunet.se>> ha scritto:
>
>
> Hello
>
> Today I represent the "unnamed FIDO wallet" project (aka
> wwwallet.org <http://wwwallet.org>).
> This is a project started by GUNet, Sunet and yubico with the goal of
> building a FIDO-based wallet based on OpenID4vc and vp profiles and
> sd-jwt credentials.
>
> We would like to propose this project for inclusion in idpy.
>
> The project is in an early phase but we are confident that it has the
> potential to become a staple of the wallet ecosystem because of its
> simple design. The organizations are currently funding the work within
> the framework of the EU digital wallet LSPs
>
> The backend of the project is python and pretty clearly in scope of the
> idpy family of projects (beeing all about identity) but since there is
> web involved there are other technologies present such as html and js.
> We believe python-based WASM could play a role in the project in the
> future. Our goals is to make a scalable fully secure "cloud" wallet
> with
> support for multiple credential and registry technologies.
>
> The project is in its infancy but needs an organizational home. Funding
> is not a problem for the next few years at least at which point we hope
> interest in a web based FIDO-wallet will make this a self-sustaining
> part of the idpy family. The project does not have a separate webpage
> yet and we are hoping for a decision in idpy before we bring the first
> public version of the code into the idpy org on github. We plan to
> publish under a BSD-2 license.
>
> We are already well integrated into the idpy family of projects and
> plan
> to use satosa as our primary issuer/verifier implementation for testing
> and development.
>
> A public demo is available at demo.wwwallet.org
> <http://demo.wwwallet.org>
>
> Best R
> Leif
> _______________________________________________
> Idpy-discuss mailing list -- idpy-discuss(a)lists.sunet.se
> <mailto:idpy-discuss@lists.sunet.se>
> To unsubscribe send an email to idpy-discuss-leave(a)lists.sunet.se
> <mailto:idpy-discuss-leave@lists.sunet.se>
>
>
> ------------------------------------------------------------------------------------------------------------------
> Il banner è generato automaticamente dal servizio di posta elettronica
> dell'Università della Calabria
> https://www.unical.it/5x1000 <https://www.unical.it/5x1000>
Hello
Today I represent the "unnamed FIDO wallet" project (aka wwwallet.org)
This is a project started by GUNet, Sunet and yubico with the goal of
building a FIDO-based wallet based on OpenID4vc and vp profiles and
sd-jwt credentials.
We would like to propose this project for inclusion in idpy.
The project is in an early phase but we are confident that it has the
potential to become a staple of the wallet ecosystem because of its
simple design. The organizations are currently funding the work within
the framework of the EU digital wallet LSPs
The backend of the project is python and pretty clearly in scope of the
idpy family of projects (beeing all about identity) but since there is
web involved there are other technologies present such as html and js.
We believe python-based WASM could play a role in the project in the
future. Our goals is to make a scalable fully secure "cloud" wallet with
support for multiple credential and registry technologies.
The project is in its infancy but needs an organizational home. Funding
is not a problem for the next few years at least at which point we hope
interest in a web based FIDO-wallet will make this a self-sustaining
part of the idpy family. The project does not have a separate webpage
yet and we are hoping for a decision in idpy before we bring the first
public version of the code into the idpy org on github. We plan to
publish under a BSD-2 license.
We are already well integrated into the idpy family of projects and plan
to use satosa as our primary issuer/verifier implementation for testing
and development.
A public demo is available at demo.wwwallet.org
Best R
Leif
*Idpy meeting 26 September 2023*
Attendees: Ivan, Johan, Matthew, Hannah, Shayna
0 - Agenda bash
1 - Project review
a. General -
- Kushal Das - new to idpy - will initialyl focus on configurations
b. OIDC libraries - https://github.com/IdentityPython (idpy-oidc,
JWTConnect-Python-CryptoJWT, etc)
- Matthew is deploying satosa-oidcop. What are the plans for integrating
this with a new release of SATOSA? The old oidc-op does not work out of the
box with SATOSA 8.4 and the current version pyop. Since this is kind of a
breaking change, his recommendation is to go ahead and make the jump to the
new satosa-oidcop. Enterprise deployments don't work with old version of
oidc-op since pymongo has moved on. Matthew has concerns over the docker
container - it should be release quality for enterprise users. He would be
happy to bake satosa-oidcop into the next version of the container. Or
should he stay in lock step with SATOSA releases?
- Ivan says they can make changes to make pyop work and release. Will
leave it in since some people are using it.
- The plan is to keep everything and allow people to use frontends by
including them and configuring them on the deployment side.
- the plan is not to include satosa-oidcop in the SATOSA repo. It has
its own repo with its own lifecycle and dependencies. They will
keep things
aligned, though, since people will be using it and will report
if something
breaks.
- satosa-oidcop could be brought into idpy but it is up to Giuseppe.
- There is another frontend that should have been released already by
GÉANT but Christos was at TechEx and has had some obstacles. That would
also be a separate repository with its own release schedule.
- Ivan says it is ok to incorporate multiple frontends into the
container and allow the user to configure whichever ones they want.
- SATOSA is intended to be a building block - the docker image is the
integrator so that you can actually use the product and bring it
up. SATOSA
is the core.
- Roland's PR to separate SAML parts from SATOSA is evidence of this
separation. We shouldn't have to build with pysaml2 in SATOSA if
you don't
need it. You could even use another SAML library. SATOSA is a
plugin system
that gives you a core internal abstraction of information for
authentication and authorization which is then translated to
multiple other
protocols, and you can use whatever libraries you want to use.
- Matthew still has a PR on pyop.
- Ivan has questions on how to use idpy-oidc to configure a client that
wants to use the client secret jwt authentication method - will post to see
if Giuseppe or Roland can answer
c. Satosa - https://github.com/IdentityPython/SATOSA
- Matthew is sending slides to the mailing list for single logout that
were presented at TechEx. Meeting will be 10/4.
http://internet2.edu/wp-content/uploads/2023/09/20230920-sebuliba-satosa-sl…
.
- A new SATOSA release is imminent. There are few more PRs to merge:
- - https://github.com/IdentityPython/SATOSA/pull/427 - SATOSA maps
between protocols using configuration that lists what should happen with
particular profiles. Apple does things differently - it returns
attributes/claims that are dictionaries with their own keys and values.
This causes conflicts when trying to look up mappings. The choice is to
either make the code more flexible, not throw exceptions and just ignore
those keys/mappings, or separate Apple to it own profile, which
would make
things things more verbose but also more explicit. Since things are only
slightly different with Apple signing, Ivan's first instinct is to merge
with the oidc backend and make code more flexible. But if Apple changes
more things (which is likely) , we should probably be treating it as
something different.
- - https://github.com/IdentityPython/SATOSA/pull/419- has to do with
how we map some concepts between saml and oidc. It is mapping saml's
is_passive to another concept within oidc, which is the ability
to request
offline access to the user's information even when the user is
not present,
which oidc recommends using a prompt for the user to approve. This MR is
about making is_passive a hint to disable the prompt. (prompt = no). Oidc
spec allows this but strongly recommends using the prompt. We should make
this something that is explicitly configured - available but disabled by
default. Needs some work - Code changes and documenting the
option and its
consequences clearly.
- https://github.com/IdentityPython/SATOSA/pull/441 - SATOSA yaml
parser needs to be extended. Already merged.
- https://github.com/IdentityPython/SATOSA/pull/442 - Roland's work.
There is some work to be done with correctly configuring the
dependencies,
and adding error messages when SAML is not there - alert user
that if they
want to use saml, they need to take special action now. This is
a breaking
change so will probably not be merged right now, it will be in its own
release - with info how to get previously expected behavior.
- https://github.com/IdentityPython/SATOSA/pull/435 - still thinking
on this one - once it is done, people will expand and use the
typing - may
bring in Kushal on this one. Open to suggestions.
d. pySAML2 - https://github.com/IdentityPython/pysaml2
- Not much work done recently - minor updates on dependencies - merged a
PR about clearing up log messages.
- https://github.com/IdentityPython/pysaml2/issues/917 - issue with
importlib-sources. -Python support provided the ability to manage
files/folders (resources) - you could ask the package for info on resource
and didn't need to know the specific path. In the next release they
deprecated some functions that were being used. Now things are breaking for
all Python versions - need to figure out how to do things in a different
way.
- Matthew E wrote something similar for a personal project- uses
packageutil and importlib. Matthew will send to Ivan and Ivan will take a
look to see if it's helpful.
- Python packages are zip files - there are ways to install without
unzipping. So sometimes you are not looking at actual files and
directories, but instead you are looking at a virtual unzipped image in
memory. At that point the path is a virtual thing - a memory
pointer. Ivan
needs to figure out how to reach into these virtual places using the
methods that are left.
- Ivan will look into open issues and then prepare a release for
pysaml2
e. Any other project (pyFF, djangosaml2, pyMDOC-CBOR, etc)
- a new release of pyXMLSecurity came out August 24 - semantic
versioning was added. One PR had to do with self signed or CA certificates,
whether the signature is correct. pysaml2 backend can also use
pyxmlsecurity - Ivan needs to check that it still works.
- waiting for new release for pyff
- FED CM - there are recent developments in the w3c privacy group and
the federated identity community group (previously the federated credential
manager community group) - chrome has a new API they are proposing called
FedCM - to work around google identity access management library that
relies on third party cookies. They want to kill link decorations as well -
they'll break saml, oauth2, oidc, etc. When an IdP needs to do something,
or a RP needs to send a user to an IdP, FedCM can instruct the browser
using this javascript API to get consent from the user to allow the link
decoration and third party cookies before going to the next "hop". For
authentication intermediaries, there are a lot of implications with this.
People involved in talks about this: Zacharias Törnblom (Sunet), Philip
Smart at Jisc (has a demo) , Chris Phillips (Canarie), Leif, Albert Wu,
Nicole Roy, Scott Cantor. See:
https://wiki.refeds.org/display/GROUPS/Browser+Changes+and+Federation
- This will be a particular problem for Research Collaborations using
the AARC blueprint
- These escalation prompts may hide discovery and drive idp toward
Google
- Google will turn this on progressively, possibly starting in
November.
- Invite Judith Bush to talk ?
- questions on whether this will actually move forward, who will
follow suit- Chrome and Google is what we're talking about here
-Mozilla &
Microsoft are more into those discussions. Apple/Safari seems to be doing
its own thing. Vittorio Bertocci was also in the discussion but
has dropped
due to illness. The companies he was involved in, Okta and Auth0 , are
against the changes - also probably the banks . Google wants to
enable but
keeps postponing - saying 2024.
2 - AOB
- Next meeting 10 October 2023
Thanks,
Shayna
