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
There will be a review of PR-431
<https://github.com/IdentityPython/SATOSA/pull/431> on 4 October 2023 from
13:00 to 14:00 UTC.
Please let me know if you would like to attend and I will add you to the
meeting invitation.
Thanks you,
Shayna Atkinson
satkinson(a)sphericalcowgroup.com
Idpy meeting 12 September 2023
Attendees: Giuseppe, Ivan, 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)
- Review of Matthew E's pull request
<https://github.com/IdentityPython/pyop/pull/52> on pyop and
continuation of discussion that was started in Slack.
- Summary : pyop (somewhat deprecated) is not compatible with PyMongo
version 4+. Yet SATOSA depends on pyop for the OIDC front end.
Pull request
is a one line pin to the old version of PyMongo.
- If the new front end is the way of the future, there should be some
documentation that indicates that pyop should not be chosen for new
deployments of OIDC.
- Ivan could not find an example of a client connecting to the
frontend; he should probably provide some examples of static and dynamic
client registration.
- Ivan says pyop is not deprecated but is also not properly
maintained. Most of the effort is being put into idpy-oidc. However, pyop
can still work with restrictions on dependencies. At some point pyop will
be archived and everything will be switched to idpy-oidc. When this
happens, they will not remove the existing packages/frontends that are
available on SATOSA. Instead, deployers can choose to use either
the old or
new frontends/backends. So pyop is not replaced; the deployer
chooses which
ones to use. Pyop code base will no longer be supported by the team, but
developers can make their own forks and make changes as they wish.
Deployers will be pushed toward idpy-oidc. however, since this
is where the
focus will be. This would appear to make it so there is not a breaking
release; however there will be one just due to the special
syntax required
to declare the dependencies you want. For instance you usually say:
pip install satosa
but then you will have to say something like:
pip install satosa[idpy_oidc_backend]
or
pip install satosa[idpy_oidc_backend,saml2_frontend]
etc.
This is already done for the new backend - example in
https://github.com/IdentityPython/SATOSA/blob/628ee94/setup.py#L34 line 34.
If you specify idpy_oidc_backend then this pulls in at least version 2.1.0
of idpyoidc. There will be similar things for saml, etc. and it is already
available for choosing mongo or redis:
"pyop_mongo": ["pyop[mongo]"],
"pyop_redis": ["pyop[redis]"]
- This does have implications on the container/packaging side. The goal
is to be more inclusive, but people can always create their own
containers.
- This document talks about other repos relevant to SATOSA -
https://github.com/IdentityPython/SATOSA/blob/master/doc/README.md#external…
One is satosa-oidcop.
- Roland has requested to change how work is done in the idpy-oidc repo.
Previously there were both main and develop branches, and all work was done
locally against the develop branch. Eventually the develop branch would be
merged back to the main branch and there would be a new release. Roland
proposes working on the main branch directly. Releases are tagged as
necessary.
- Christos and Roland are going to make a release of the OIDC frontend
that is used by eduTeams, probably this week.
- Note: satosa-oidcop is working with MongoDB/pyMongo; the one used by
GEANT eduTeams uses postgres. Doing this with something like Alembic might
be better in the future. Some of the reason for using Mongo was based on
that Roland initially coded using the filesystem for the storage layer, not
a relational approach. Using a relational database requires rebuilding all
the relationships, do cleanup, etc. Giuseppe used the load() and dump()
abstract interface to the internal session storage engine. You can see
practical examples of when these methods are used in satosa-oidcop.
c. Satosa - https://github.com/IdentityPython/SATOSA
- Roland's PR for removing saml dependencies:
https://github.com/IdentityPython/SATOSA/pull/442
- Need to thoroughly review and make sure nothing else breaks. Also
includes replacing some cryptographic operations with cryptography and
cryptojwt libraries.
- Ivan is preparing a new release
- Looking at these PRs
https://github.com/IdentityPython/SATOSA/pull/435 - typing
https://github.com/IdentityPython/SATOSA/pull/438 - saml modules metadata
store
https://github.com/IdentityPython/SATOSA/pull/431 - SLO
- Should the state storage be part of a specific module like saml
backend, or part of core so that any module can use it?
- Requires proper storage that can outlive a reset of SATOSA
- Could be Redis, could be something else, abstract? Redis has
a nice API and Graph database, but there are legal aspects
to its licenses
- Giuseppe shared an abstract storage layer example :
https://github.com/italia/eudi-wallet-it-python/blob/dev/pyeudiw/storage/db….
See line 18 - can use multiple storage engines.
- Giuseppe also shared
https://github.com/italia/eudi-wallet-it-python/tree/dev/pyeudiw
- uses MongoDB by default
- abstraction allows things to be "future-proof", but
abstraction also sometimes prevents being able to use
special features of a
particular solution
- Will also look at how to further separate the core: redoing some of
the login work, enhancing the internals
d. pySAML2 - https://github.com/IdentityPython/pysaml2
- upcoming release , then will continue with other open PRs
- Nice work done regarding having configurable encryption algorithms:
https://github.com/IdentityPython/pysaml2/pull/924
e. Any other project (pyFF, djangosaml2, pyMDOC-CBOR, etc)
- djangosaml2 is stable; Giuseppe is waiting for revisions to be done
that he asked for from developers
- pyMDOC-CBOR - package was started to give guidance to the Italian
community of developers implementing the wallet solution. The community has
decided not to implement MDOC-CBOR for now, but it is a requirement so
development will continue.
- There was a new release of pyXMLSecurity; waiting for new release for
pyff - try to discuss these next time
2 - AOB
- Next meeting 26 September. Giuseppe not sure if he will be there.
Thanks!
Shayna Atkinson
*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_tr…>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-ref…>
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-…>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*
