Dear EUGridPMA and IGTF members, The 35th EUGridPMA meeting is now over. It was fun organising it, and I thank everyone who came over to Amsterdam to enjoy the (rainy) city, or the large number of folk from all over the EMEA region who joined us over video for meeting! This summary and the minutes kindly taken by Ian Neilson and Licia Florio are on-line, alongside some of my own scribbles, but meanwhile I would like to share with you a few of the highlights of the meeting. Send corrections and omissions if you spot them! Specifically FOR THE TAGPMA and APGridPMA: The Generalised LoA document has been clarified for readability, but is materially identical to the original versions (no change in assurance was intended to be introduced). The PKI technology Guidelines are NEW. Both taken together should in due time replace Classic, MICS, SLCS, and IOTA, so please review also the PKI Tech Guidelines (see below) for consistency. Comments welcome! We explicitly expect TAGPMA to discuss the PKI Technology Guidelines (and consider re-wording the APs managed by TAGPMA). Subsequent EUGridPMA meetings will be: ** 36th EUGridPMA meeting, 18-19 January 2016 in Bratislava, SK, kindly hosted by SAVBA, Miroslav Dobrucky and Jan Astalos ** 37th EUGridPMA meeting, 9-11 May 2016 in Ankara, TR, kindly hosted by Feyza, TR-Grid and ULAKBIM ** 38th EUGridPMA meeting, September 2016 in Geneva, CH, kindly hosted by Paolo Tedesco and CERN ** 39th EUGridPMA meeting, January 2017 in Firenze, IT kindly hosted by Roberto Cecchini of GARR and INFN ** 40th EUGridPMA meeting, May 2017 in Ljubljana, SI kindly hosted by Jan Jona Javorsek of the Institut "Jozef Stefan" and other meetings - TAGPMA22, 30 Sept - 1 Oct 2015 in UNAM, Mexico City, MX - REFEDS and I2TechX, Oct 4 and 5-7 2015 in Cleveland, OH, USA - EWTI, REFEDS and FIM4R, 30 Nov - 4 Dec, Vienna AT see https://identityworkshop.eu/ - APGridPMA and ISGC, 13-18 March 2016, Taipei, TW - TNC2016 + REFEDS, 13+14-16 June 2016, Prague, CZ See all of you at one of the upcoming meeting of the IGTF or elsewhere! Slides with background of the Amsterdam meeting are attached to the agenda pages at ! Best regards, DavidG. Subject discussed and listed below ---------------------------------- - LoA generalisation document clarification - PKI Technology Guidelines - Updates to the Classic AP - HSMs and splitting of EJB CA - KENET CA accreditation - AARC and AARC Policy Harmonisation - LoA activities outside the IGTF and R&E communities - LoA feasibility assessment and AARC/GN4 questionnaires - Risk Assessment Team and Communications Challenge - CERN WebFTS and CERN STS IOTA CA - RPS updates - Higher Level CA (HLCA) updates - Status Updates of accredited authorities and ongoing accreditations - Miscellaneous topics and notices - Questionnaire responses - GEANT4 IdP Questionnaire - Federation Questionnaire All presentations are available on the agenda page: http://www.eugridpma.org/agenda/35 please review these as well as a complement to this brief summary. Much information is contained therein and not repeated here. Generalized IGTF Levels of Authentication Assurance --------------------------------------------------- The LoA generalization process aims to extract those elements from the IGTF APs that are of general value to the community beyond just PKI. This process has resulted in a single comprehensive document, the "IGTF Levels of Authentication Assurance", that provides for four LoA definitions, three of which are comparable but employing different security controls, trading off credential validity period vs. retention of tracability. The latest version 0.10 of the generalised IGTF LoA document is now available at http://wiki.eugridpma.org/Main/IGTFLoAGeneralisation The following changes were introduced in the EUGridPMA meeting: - the readability was improved by re-ordering the LoA tables. All sections now start with the common elements, and the per-LoA distinctions are highlighted in specific boxes. Reformatting is intended to improve readability. - some duplications were removed from the text, and a few lingering PKI specific elements (in particular protection strength requirements) recast in a more neutral way. - the ambiguity on the use of anonymous credentials in DOGWOOD (IOTA) has been removed - no anonymous credentials should be used and a name (pseudonym, opaque identifier, or even a real name) must be included in the credential - extension of credentials based on hardware tokens of at most 5 times 400 days is now clearer (it can be "extended or renewed up to 4 times ...") You are specifically asked to review the document to ensure that the four levels (ASPEN, BIRCH, CEDAR, DOGWOOD) are an accurate reflection of the current assurances provided by the SLCS, MICS, Classic and IOTA AP. PKI Technology Guidelines ------------------------- Accompanying the technology-neutral Generalised LoA is a new document, identical and application for ALL authentication profiles(!), that contains the technical requirements on accreditation for PKI-based accredited authorities. The PKI Technology Guidelines document is now at version 04: http://wiki.eugridpma.org/Main/PKITechnologyGuidelines and has been reviewed by the EUGridPMA. This document should apply to *all* PKI-based authorities, be they Classic, MICS, SLCS, or IOTA. Having a common document ensures consistency in the distribution, and makes it easier to maintain the requirements. The result will also be significantly shorter (3-line!) authentication profiles. The PKI Technology Guidelines do not contain specific assurance level requirements, but do implement some of more 'abstract' specifications from the Generalised LoA document (e.g. "strength equivalent to 112-bit symmetric" becomes "RSA-based end-entity keys must be at least 2048 bits long"). Please review these guidelines and send comments to the list! Updates to the Classic AP ------------------------- Once the Generalised LoA document and the PKI Technology Guidelines are accepted by the IGTF globally, the existing authentication profiles can be re-worded. The current distribution will still be based on these profiles (that will retain also their name and OID), but the wording will be much simplified. The proposed new version of the Classic AP (5.0) would read only: " Authorities accredited under this IGTF "Classic" profile, identified as 1.2.840.113612.5.2.2.1, must comply with the latest endorsed version of * the IGTF Level of Identity Assurance CEDAR (1.2.840.113612.5.2.5.3); and * the IGTF PKI Technology Guidelines (1.2.840.113612.5.2.7.1). " which would be the entire AP (apart from some introductory text). The current draft of 5.0 is at http://wiki.eugridpma.org/Main/ClassicCASecuredInfraAP The other APs (EUGridPMA will take care of IOTA) can all be as simple. HSMs and splitting of EJB CA - KENET CA accreditation ----------------------------------------------------- Taking elements from a lot of sources, and with a lot of innovative ideas, Ronald Osure from KENET has constructed a new on-line CA, with an HSM backing and a split-publication system based on EJB-CA. This system, implementing a hybrid of the on-line CA guidance models "A" and "B", has the requesters separated on a dedicated network talking to the CA, and the public managing validation on a separate service. Combining EJB CA, drivers for the Gemalto IDPrime MD3810, and an Ubuntu Linux system, the result is an on-line CA that is cost effective, secure, and easily replicable by others. Review Ronald's presentation at https://indico.nikhef.nl/getFile.py/access?contribId=10&resId=0&materialId=slides&confId=201 if you want to build a similar system. Ronald is happy to help and share his (by now quite extensive!) experience is getting this to work! As to the accreditation of the KENET CA that this was all built for: - some minor technical inconsistencies (RDN order in the ASN.1 sequence, add email address in SAN) will be fixed soon - the on-line issuing CA will grow an off-line Root that will sign it as an intermediary, so that in principle the on-line CA can be revoked. The Root will have the typical 400-day CRL. - Once these technical changes are complete, the CA will be added in the distribution for testing (initially as "unaccredited") - by 1.68 - once Marc and Roberto complete the review - which may take a few more emails - it will move to accredited. The target date for that is the end of October 2015. Authentication and Authorization for Research and Collaboration (AARC) ---------------------------------------------------------------------- The AARC Project, https://aarc-project.eu/, has started and now active in various areas: architecture design for an integrated AAI that build on existing work and addresses identified gaps - with a special focus on integrating attribute providers, 'guest IdPs', and considering token translation services; with a training package targeting IdPs and user communities as well as decision makers; and an evolving set of pilots to streamline access to resources (clouds, non-web, etc); and of course a package on policy harmonisation and best practices. There are 18 months left to run for AARC, resulting in a blueprint architecture and a set of policies and recommendations that are complete by early 2017. However, mostly due to the timing of the EC work plan, we should already start thinking now on how we can further develop the results of AARC beyond its conclusion - with an increased focus on 'user driven innovation'. Ideas from the wide community on this are welcome - communicate them to any AARC leaders or just drop a mail to Licia Florio, the AARC project coordinator. Such a successor project would need to be submitted by March 2016. For a full overview, see Licia's presentation to the PMA at https://indico.nikhef.nl/getFile.py/access?contribId=14&resId=0&materialId=slides&confId=201 AARC Policy Harmonisation and Best Practice ------------------------------------------- One of the packages of AARC of specific interest to IGTF would be the policy harmonisation work. It addresses security incident response policies, protection of accounting data, sustainability of identity and attribute services (and guest IdPs), coordination of levels of assurance for both identity and attributes, and effective mechanisms to scale policy negotiations. The work on assurance levels coordinated by Mikael Linden bears the closest relation to the IGTF - the initial mile stone will be to define a level that is both achievable by identity providers (also in the R&E federation/SAML space), as well as useful for relying parties and some research/scholarly service providers. Finding a sustainability model for generic IdPs - or to support 'higher' assurance levels - is als a continuing challenge. In the 'SAML space', all generic IdPs have in the long term gone out of business or started charging either users or the service providers (ProtectNetworks the latter, whereas Feide's OpenIdP is closing down by the end of the year). We see similar challenges in the IGTF, where CAs have stopped service unless there was a community of users/relying parties with active need and willingness to fund the CA behind it (Ireland, Latvia, ESnet, ...). Having a scalable model for negotiation of agreements between identity providers and the relying parties is also not to be taken for granted. Within the IGTF this has been addressed with our minimum requirements and a policy-bridge architecture - and by making the release of some (personal) data less legalistic by having the user explicitly involved in each action: certificates are used by the end-entities themselves. But in the R&E 'SAML' federations, the mechanisms are found to be less scalable - and FIM4R has identified the need for better mechanisms. The Data Protection Code of Conduct ("GEANT CoCo"), and the (REFEDS) entity category of 'research and scholarship' (R&S) aim to facilitate automatic release of useful identity information. But then also scoped entity categories have emerged i several countries and for some communities. For a full review and the list of questionnaires (and questions) see David's talk at https://indico.nikhef.nl/getFile.py/access?contribId=15&resId=0&materialId=slides&confId=201 LoA activities outside the IGTF and R&E communities --------------------------------------------------- Also of note is the EU government effort on eID and assurance. The "Implementing Regulation" (Sept 8) sets out the technical specification and procedures for assurance levels for eID, and is the 'final' version of the earlier consultation process - thanks to Mikael Linden for sharing http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.L_.2015.235.01.0007.01.ENG It defined three levels of non-trivial LoA (like any other framework ;-), here labelled "low", "substantial", and "high". How and when this framework will appear in the various EU member states ... we'll see ... the rest of the EMEA region may not care anyway ;-) For those who consider a simple LoA scale to flat, the work of the VoT "Vectors of Trust" in the IETF should enter provide a four-dimensional hypercube of different aspects of assurance: ID proofing, credential usage, credential management, and presentation of the assertion; with renderings for SAML, OpenID Connect, etc. https://tools.ietf.org/html/draft-richer-vectors-of-trust-01 LoA feasibility assessment -------------------------- AARC and GEANT4 would like to enlist the help of the community to assess feasible and usable assurance level specifications by help of a few short questionnaires. The GEANT4 effort (lead by Daniela Poehn) focussing on the identity provider and federation elements, the AARC effort (lead by Mikael Linden) on relying parties and service providers. Given the structure of the IGTF, we can based on the APs, answer a lot of the IdP and federation questions centrally. For the SP questionnaire, we would like to ask if you could consult your local or national user base if they are willing to contribute answers. IdP survey https://wiki.geant.org/display/gn41sa5/IdP+survey Fed. survey https://wiki.geant.org/display/gn41sa5/Federation+survey SP survey https://wiki.geant.org/display/AARC/Level+of+Assurance+survey+for+SP+communities During the meeting, the accredited authorities present, in their role of identity providers for their constituency, could answer to the IdP and Fed questionnaire. They are listed at the end of these notes. Communication Challenge and Risk Assessment ------------------------------------------- The IGTF Risk Assessment Team is open to everyone, and currently the list of members, although having global 24hr coverage, is small in numbers. This also does not help in running the RAT Communications Challenge (RATCC), which now fully rests on Ursula. Some ideas to make it easier to run the RATCC: - add a ticketing system. Ian Neilson is setting one up in the UK for the national NGI CSIRT. Ian can check if that can be extended for the RAT. Also Walter de Jong is willing to help out with the RATCC - not all RAT CC contributors need to be also on the RAT, so it is not a never-ending complex task. Relying parties would appreciate a yearly RATCC run. WebFTS at CERN, FIM4R and the CERN wLCG IOTA CA ----------------------------------------------- The "WebFTS" service in the LGC Computing Grid is a file transfer and management service allowing users to manage data transfers in e.g. wLCG. It can leverage federated authentication ("FedAuth") so that users can login with their home institute credentials. Above translation can be achieved using an on-line certification authority (CA) via the STS Security Token Service. A dedicated CERN IOTA CA (signed off the existing CERN trusted root) can serve this use case (and potentially also be a generic IOTA CA for all listed/eduGAIN IdPs, although this is for now out of scope). See Paolo's slides at https://www.eugridpma.org/review/ca-cern-iota/CERN_LCG_IOTA_CA_-_EUGridPMA_2015_Amsterdam.pptx and the draft CP/CPS document at https://www.eugridpma.org/review/#cerniota This STS IOTA CA will be based on the STS and authentication through eduGAIN. The CERN login system (SP proxy) is already linked to eduGAIN, usually for limited accounts/services. The STS CA will only issue credentials to members of the Atlas LHC VO, whose membership is recorded in the VOMS community management system. For this purpose, the user database entry also contains the eduPersonPrincipalName (ePPN) value, which is added to an existing X509 subject DN (so the user enrolment is for now still based on the user also holding a cert). As per figure on slide #8, the WebFTS service (blue box) will generate for each connected user (that is authenticated through the CERN SSO system) a key pair, and the public part thereof is sent to the STS service (yellow box) so as to obtain a proxy cert. In order to sign the proxy cert, the STS will also generate a key pair (one for each user), of which the public part is sent over to the IOTA CA, who will sign it with its own ICA intermediate CA cert. In the initial design, the STS would then sign the (WebFTS generated) public key of the proxy and proceed to delete the key pair generated by the STS itself. However, if the IOTA CA is relatively 'slow' (since it MUST have an HSM, which was not yet foreseen, and the affordable HSMs are limited to a few sigs per second), it MAY cache the IOTA-signed user credential as per the PKP guidelines (as a "trusted third party") and keep them for the maximum validity period of up to 400 days. Of course, unless the user actually makes continued use of the credential in the STS, it has to be deactivated (and since it has no other protection means: destroyed) after a longish period of inactivity, and cannot be stored on disk (so after a reboot the user just has to get a new cert in the STS signed by the IOTA CA). The STS could thus 'grow a cache function' as well. The IOTA CA MUST use an HSM, since it is on-line. This can be an affordable HSM like the one used for the KENET and NIIF setup (e.g. Gemalto IDPrime MD3810 + K50). Other comments - the scope of the ePPN received from IdPs should preferably be checked against the permitted scope (a shib-specific attribute) in the SAML federation meta-data - for the accreditation of this CA, the VOMS binding is out of scope: it could as well be a completely open eduGAIN bridging IOTA CA ;-) - the VOMS checks do bring specific value to RPs in absence of software that can authorized based on VO+CA combinations - time line: end of September will see a new CPS with an HSM - it would help to align and not duplicate terminology like "intermediate" Registration Practice Statement ------------------------------- Some updates and textual improvements were done on the RPS. The changes are tracked in the document, with the latest version as always at https://wiki.eugridpma.org/Main/RPS as https://wiki.eugridpma.org/pub/Main/RPS/RPSTemplate-Sep2015-EUgridPMA.docx where also further updates can be attached and managed. Higher Level CA guidelines -------------------------- The HLCA document v0.11 was reviewed and made available on the PMA Wiki at http://wiki.eugridpma.org/Main/HigherLevelCAProfile Given that some of the use cases have not yet materialised, it may help readability if the alternative are not (yet) explicitly listed in the document. Auditing, accreditation, and compliance --------------------------------------- The self-audit peer reviews of CERN IT/IS, PK-Grid, MaGrid, and NIIF, were declared complete (some already some time ago) and need no longer be tracked. For the other cases (see https://wiki.eugridpma.org/Members/SelfAuditStatus) the peer reviewers are asked to review the material in a timely fashion, and the CAs who still need to update their CP/CPS are urged to do so quickly. Miscellaneous topics -------------------- - the tag, originating in Netscape a long time ago, is being deprecated in Chrome within the year, with Mozilla likely to follow as well. Google Chrome on MS Windows actually never worked for enrolment. Also, given that ActiveX is not supported in MS Edge, with the demise of IE the Windows platform will not have a browser-based key generation system. Generally, browser vendors attempt to push credential enrolment and management to the operating system layer, whether the OS actually supports that or not. This means that CA enrolment systems that are browser based need to be updated. Good examples are based on the work at the UKeScience CA and at SiGNET, leveraging "forge.js" javascript-based X509 functions. The only downside: from javascript (or HTML5) one cannot set proper operating system file permissions - this is a risk. Jens should share the work by David Meredith and the testing by John Kewley with the IGTF community on the igtf-general@igtf.net list. - Several countries have both the traditional eScience CA as well as access to the GEANT TCS service. A common issue that prevent moving to TCS remains the availability of the service to eScience collaborators who are not eligible for TCS: either because the TCS is offered through the NREN who cannot or will not support pre- and non-competitive research depts in the private sector, or because they chose a national pricing model that does not do justice either to the TCS idea nor is compatible with the eScience use cases where large numbers of nearly identical certs are required. Such national differences, but especially any pricing 'per certificate' is extremely detrimental to the eScience and e-Infrastructure use case. It should be remembered that the very idea of TCS was to be flat-fee unlimited, so that 'there should be no reason not to have a proper cert'. - several CAs (INFN, NorduGrid) will need to re-issue or re-generate their root CA credentials. - there has been no observable progress on the use of the JICS Cert Service for e-Science use cases, nor on client certs or escience certs therein. Also the update of the REFEDS R&S EC in JISC is very slow. Questionnaire responses ----------------------- * IdP Questionnaire ----------------- 1.Identity/account concept - Account for an individual person (i.e. there are no shared accounts)? * There are no shared credentials or accounts by policy - although the policies allow for specific "machine-to-machine" authentication credentials ("Robots"). For these Robot certificates, they are either uniquely tied to a named individual person (effectively giving that person a secondary credential); linked to a named networked entity (by FQDN); or assigned to a group of people with compensatory controls: one named person must act as the applicant and responsible person, but the credential may be used by an identified group in possession of a shared email contact address, but any messages to this address must be responded to within one business day. - If shared: possible to distinguish between individual and shared accounts? * The machine-to-machine credentials are identified by the substring "Robot " in their subject name, and a specific policy OID (attribute) in the credential - If individual account: traceable? Are identifiers persistent? * one entity may have more than one ID but an ID cannot be reassigned to a different entity (this also holds throughout the IGTF federation globally, using scoped identifiers) - Which unique identifier? * the subject name of the credential is used (for PKI). Depending on the assurance level, it will contain also the real name of the person involved. 2.Registration and proof of identity - What identity vetting process? Face-to-face or different? * The IGTF supports differentiated assurance. For the 'conventional' assurance levels (designated ASPEN, BIRCH and CEDAR), a face-to-face identity vetting or equivalent is required. F2F is supported in-person with official photo-ID; supported by notary public attestations and video conference; or by exceeding Kantara LoA-2. For the identifier-only ('lower') assurance level ("DOGWOOD"), only enough information needs to be collected to ensure uniqueness - there is no F2F requirement there. - Documented? * All vetting processes and possibilities are document at each IdP, and meet or exceed central federation requirements. - Different validation between student, staff or faculty members? How? * All members are validated equally 3.Online authentication - Passwords? * in the PKI infrastructure certificates have to be issued, so these do qualify as 2-factor authentication. This statement has to be qualified slightly: since the key pair is controlled by the user, a pass phrase on the credential cannot be fully technically enforced. Policy requirements, user induction, and software support strive towards having strong pass phrases, making it a two-factor secured system. In some cases, especially for identified based on other (federated) IdM systems ("MICS, SLCS, IOTA"), the second factor/certificate is obtained based on a username-password authentication (GEANT TCS, DFN SLCS, CILogon, HPCI) - Passwords with quality guarantees? What kind of guarantees? * By policy, end-user pass phrases must be at least 12 characters - this is not technical enforceable, but is technically stimulated (it is hard to not have a pass phrase). Key pair is usually a software token (file-based) - Two factor authentication? * Yes, by default 2 factor. It is to note that the 2-factor authentication is partially there for convenience in (non-web-sso) authentication scenarios and to anchor attribute certificates to it. When in use, a (kerberos-ticket-like) proxy credential with short (~12hr) validity is created based on the credential. The other advantage because of which 2FA certs were chosen is that these are self-contained and thus resilient to any (network) failures -- there is no single point of failure in the PKI - esp. since also the revocation data (CRLs) are cached by the relying parties and services. The relying parties (SPs) do not now have an opinion yet as to whether this 2-factor auth would be a hard requirement for most of their use cases. - If yes, which second factor? Is the eID used? * a PKI certified asymmetric key pair, usually held in software (file). * eID is not used - If no two factor authentication: How big would be the cost to provide two factor authentication? There is no incremental cost to provide the second factor (cert), although there is some cost to generate the certificates (people time needed for issuance). Cost would increase if the second factor would be on a hardware security token. Given software limitations, the cost of NOT providing two-factor has been high until now. - how widely Home Orgs use government IDs i.e. strong authentication the governments use for authenticating citizens * For the conventional assurance levels (with F2F vetting) validation is based on official govt. photo ID checking at application time. No other Govt (database) authentication is used. 4.Freshness of user data - Are accounts closed as an individual departs? How promptly? * If data changes credentials must be revoked, but this relies on the users taking an action. But in all cases, at most after 400 days the credential expires. The credential contains only authentication/identity data, and does not in itself contain other attributes that may become invalid. It is very unlikely that the user will ever depart from the user (and the passprase should be lost when the user dies, rendering the credential unusable). Ability to obtain new credentials is based on ability to be vetted or on verified ongoing relationship with the issuing authority. - Is the eduPersonAffiliation value updated as an individual departs? How promptly? * ePersonAffilition is out of scope. No data beyond identity data is necessarily collected. Organisations may not even be named in the credential (real name and unique identifier only) 5.Step-up authentication - Step-up authentication means that the user first authenticates with a password, and subsequently with a second factor (such as by an one-time password delivered to his/her cellphone) * No immediate use case for 3-factor authentication has yet been identified, although sensitive biomedical applications could require it. Upgrading 2FA to 3FA is not being considered now. - Would you like to have GEANT/your NREN to run such a service (if it costs/if it doesn't cost)? - How many users would need such a service? 6. Provenance and level of assurance - Do you use a level of assurance? Which one? * The IGTF supports differentiated assurance levels. These levels have been co-defined by the relying parties (e-Infrastructures, active user communities) and the identity providers for feasibility and needed trust. Levels are (still) defined in the authentication profiles, but more easily read at - Is the LoA self-asserted? * No, LoA is based on accreditation with peer review of public documentation and a compliance investigation based on discussion with assigned reviewers. - Is everything documented? * Yes, a compliant policy and a practice statement are required for all IdPs. - If not documented: which costs would that be? [N/A] - Internal audits? * Periodic self-assessment are required one per year, but no requirements on the independence of this assessment exist. To prevent confusion, we would label this "peer-reviewed assessments". - External audits? * Every 2-3 years, the result of the self-assessment must be presented publicly to the accrediting IGTF body and must be reviewed by external peer reviewers. - If no audits: costs for that? - How many users need a (higher) level of assurance? * 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- password is hard to answer yes, as relying parties (SPs) have not made such a risk assessment explicit. However, it "should be consistent in requiring two factors". - Identity Management Practise Statement? * all IdPs must present and disclose to the accrediting IGTF the practice statements (in sufficient retail to permit assessment of security and identity vetting practice). * Federation Questionnaire ------------------------ [this section was not much discussed in the meeting - the draft answers given should be reviewed by the PMA - so EXPLICITLY: comments welcome!] 1. General overview - Do you have a LoA (schema) in place and which one? * Yes, as per - Do you have contracts with IdPs? * No, but there are sanctions for not complying with the requirements (e.g. on attending policy meetings and meeting the self-assessment requirements) that will result in expulsion of an IdP from the federation. - Do you require an Identity Management Practice Statement? Do you enforce it? * Yes, required and enforced. - Do you require any audits/documentations for IdPs? * Yes, required for documentation. Audits in the sense of peer-reviewed self-assessment are required periodically, and additional scrutiny is performed on accession. 2. Level of assurance - Have you made any cost analysis for introducing (a higher) LoA? Is a higher LoA want from IdPs? * No assessment has been done - and for now no relying parties have requested a higher LoA than the one provided (i.e. higher than F2F+2FA) - Any experiences, which costs IdPs have to make in order to achieve a specific LoA? * This is unknown at a federation level, and is much country- and model-dependent. In most cases, the cost of LoA is distributed to the user who has to perform the F2F vetting - Impacts on adopting LoA * Differentiated LoA has been introduced recently (adding a 'lower' "Identifier-Only" assurance level below the conventional F2F+real name), which has resulted in some relying parties and end-users being confused about the 'trustworthiness' of the credential. It is rather complex to explain to non-experts that within a single federation multiple LoA levels exist, and that these should not be automatically all treated as equal.