- people addressed from the CA point of view
Q1.
- no shared certs are used, the policy forbids that, though there are
cases for email groups for automated process (in any cases there is a
responsible person and there are conditions associated to this usage)
- if shared it is possible to distinguish between shared and individual
- one entity may have more than one ID but an ID cannot be reassigned to
a different entity
- unique ID is the real name of the person (subject DN)

Q2.
Different forms of f-2-f possible, but with two different LoA. All
process is documented
All members validated equally

Q3.
IGFT certs qualify as 2-factors but in many cases username-pwd is needed
to get the second factor (is the certs, but the password on the certs is
not guaranteed as it’s chosen by the user).
Who is using e-ID? Nobody

There is no incremental cost to provide second factor (the certs)
although there is some costs to generated the certs (and even more if
users store the cert on a secure token).

Q4.
If data changes certs must be revoked, but this relies on the users
taking an action. But at most after 400 days the certs expires.
ePersonAffilition is out of scope.

Q5.
No step-up from 2F to 3F needed. How about elixir would they be interested?

Q6.
IGTF has their own LoA framework and peer-reviewed by self-assured audits.
Need to clarify the word audit - they are internally done and
peer-reviewed process.

Check the question on no-external costs.

The question on how many user need higher LoA should be more for the
services than for the IdP. How many rely parties would accept username
and pwd? hard to answer.
The reason for having digital certs was the possibility of delegation.
Missed what Jules said.
How many services are accessible with certs only?
It should be consistent in requiring two-factors.

[notes by Licia Florio, GEANT]