Identity Provider of Last Resort (IoLR)

(Laura Paglione)

–> Is there room for a non-SAML provider? A document is displayed to the participants: the document represents the comparison of information between 2 recommendation documents - one from 2015 and one from 2018; contains information about the IdP of last resort; they are very SAML-specific; in the document there are places where there are little differences, some where there are big differences and some that don’t have space for comparison (empty slots) –> What needs to be changed in the recommendations that would satisfy the SAML? –> It would be really nice if the recommendations could be technology agnostic –> exemplify with SAML –> the newer file is reworked for international purposes –> goal of the session: We take these recommendations as given and focus on the things that are very SAML specific If there is a non-SAML specific (ECP) –> what is important for ECP that can be used for non-SAML specific IoLR Q: Is there room for a non-SAML IoLR?

• Yes, but only with Federation that would support it.;
• for authentication only, doesn’t matter (Web Auth) IoT authentication- by the time you build it, it won’t matter;
• If you don’t care about NFA

–> E.g. The research communities are using their proxy as IoLR –> Orchid has gotten some feedback that some research communities aren’t using Orchid; if Orchid were to be and IdP of LR how far off are the recommendations? –> There is one additional requirement - because of united id, which has always been MFA only; 2 reasons why people use IoLR:
1. they don’t want to do user management in the collaboration proxy

1. they require their collaborators to have MFA supporting their configuration –> there is an assumption from consumers that they are able to do multi factor; not sure it has ever been stated; I don’t know if it was a should or a must - it’s a must in the 2018 version; –> That’s not a requirement set, but do you support it or not; you expect to support it; –> Multi-factor; fundamentally broken; deploying MFA; no IDP help required IoLR removing google cap shot, made it easier for Chinese researchers to access it; cannot reach Google authenticator Q: So, MFA was not important?
   Q: Orchid has MFA but it’s not a requirement, so it wasn’t important for LAGO? Comment: if you don’t care about MFA, then everything is easy

From the list: · Instructions in local IoLR languages, no Google captcha · 5/2- ECP – useful for non-web apps; tech agnostic – must support; non- web apps (non-trivial) · 10/6 – using specific profiles; 10 belongs in an implementation profile · 1/1 – R&S is not tech agnostic; IdP must provide persistent identifiers that will not conflict with those for other IdPs · 11/13 – based on REFEDS Assurance Framework; should minimally state assurance level and coffee authentication vs. identity vetting · 13/10 – in EduGain – no tech available other than SAML the numbers are representing the corresponding numbers of the recommendations in the 2 columns of the file

Q: How much of it (document) is SAML specific? A: quite a lot of it actually - Nr. 5/2/11(some components)/10/ etc. –> ECP is about making IdP useful for non-web apps; there must be an IPA available for making the IdPs identities available to non-web apps; fulfilling that is a non-trivial exercise
–> If you’re dealing with re-assignable user identifiers then you should have at least one identifier that is not always assigned –> if the IoLR is used with other, then no IdP can overrule the other IdPs; the IoLR can identify as another IdP
–> No scope checking in open IdP –> EPBNs are not first-class citizens; rewrite it in a technology independent way; rewrite it so it doesn’t make assumptions about doing scope identifiers
–> if you’re writing a tech independent profile you need to write something down there different that 1 –> Could be put as a meta data link to the local, but it’s a local thing; –> Orchid - an example for providing a useful road map; –> 11/13 – had to do with global insurance; 13 goes higher than 11; difference between them has to do with in-person verification of credentials; but 2 independent sources of verification that are not in-person; 13 – very strong requirement, as none of the current IoLRs will fulfill that, not even clos; It could be that Research collaboration want higher assurance; Depending on who it is they might want higher assurance; depends who is it useful to; –> LAGR: What do we get and what do we want for the future? – If we can get one the REFED’s single-factor Cappuccino and send it to Jim and he will give us another certificate, but it is very expensive; Cappuccino - AL2 –> Authentication level 2 requires impossible level of passwords or MFA –> Any SP in EduGain must be able to request it –> Request to use doesn’t mean use; –> To be in Edu-Gain, does that imply any technology requirements? It is a technology; What was intended was for it to work automatically, which is not possible to do. –> The technology doesn’t exist for them to do so;

–> Google can’t do Nr. 7 but they can do 10; But then then are not using EduGain; –> Getting people to rewrite 10 would be easy, but asking them to drop the commercial rate will never happen –> Certified criteria –> You can generalize that; –> Multifactor authentication –> 14 is hard; it is technology specific