Child pages
  • Consultation: REFEDS Assurance Framework
Skip to end of metadata
Go to start of metadata

This consultation is now closed, thank you for all the inputs. 

 

Background

The AARC project and the REFEDS Assurance Working Group have developed a proposed REFEDS Assurance Framework and two assurance profiles to be used by research and education federations in order to support a variety of assurance needs from service providers.  The framework and the profiles specifically avoid the concept of "levels"  - recognising on the one hand that the required assurance needs of any given scenario, group, or service do not necessarily map neatly on to a static hierarchy and on the other that home organisations can often meet some sets of requirements in different "levels" in traditional structures but can struggle to meet the complete requirements at any given level.  The REFEDS Assurance Framework and assurance profiles intend to meet known use-cases in a pragmatic and tailored way. 

With thanks to AARC for supporting man-power to create this proposal.

Note

The Assurance Framework has placeholders for authentication profiles for which REFEDS is carrying out separate consultations.  These will be resolved into the framework before publication. 

Overview

The consultation opened on Friday 21st April 2017 and closed at 5pm CEST on Friday 9th June 2017.  This consultation is now closed. 

Participants are invited to:

  • Review and comment on the proposed Assurance Framework.
  • Review and comment on the proposed assurance profiles proposed by the framework.

Following the consultation all comments will be taken back to the Assurance working group for review and if appropriate the Profile will then be forwarded to the REFEDS Steering Committee for sign-off and publication on the REFEDS website as per the REFEDS participants agreement

The document for the consultation is available as an attachment  to this page.  Background on the Assurance Working Group is available.  All comments should be made on: consultations@lists.refeds.org or added to the change log below.  Comments posted to other lists will not be included in the consultation review. 

Change Log

Change Log for the REFEDS Assurance Framework Consultation.  Actions from these proposals can be found in an attachment.

NumberLine / ReferenceProposed Change or QueryProposer
1Section 2.2What about the other IGTF APs? Presumably CEDAR is also here if CEDAR>=BIRCH. What about ASPEN? (suggestion for Appendix)Jens Jensen
2Section 2.1There is active discussion around the major shortcomings of SAML persistent IDs because of their case-sensitivity requirements, so I worry this is going to be obsolete on day one. Perhaps the reference to specific identifiers can be left to implementation guidance and not baked in.Scott Cantor
3Section 2.1In light of recent concerns raised about the relationship between EPPN and mail attributes, it may be wise to be explicit about any assumptions that one is intended to make (or not) about that. For example, if it's meant to be assumed that a given EPPN value if found in a mail attribute refers to the same person, that isn't mandated by eduPerson, and should be called out here.Scott Cantor
4Line 166s/securitybcontacts/security contacts/Scott Cantor
5Section 4I'm really surprised that there's still no profile defined for "strong authentication, no verification" given the very consistent feedback I think IdPs have always gotten that that's the dominant requirement of a lot of projects. I think, as with InCommon Silver before, the verification requirements will prove impractical for most IdPs to meet whereas MFA is becoming very common, at least in the US.Scott Cantor
6Section 5.1The overall assurance profiles really need to be handled via AuthnContextClassRef if you intend for RPs to be able to request their use.Scott Cantor
7Section 5.1The text around the use of the EntityAttribute(s) needs to clarify whether there's an intended "authorization" semantic such that CSPs are not meant to assert the profile(s) if they don't carry the attribute. That tends to be inferred by people and that's one reason the InCommon MFA profile elected not to suggest that approach. If the profile is self-asserted by the CSP or at least if this document doesn't purport to suggest otherwise, I would reconsider that mechanism.Scott Cantor
  

The inclusion of SAML metadata entity attributes in the framework makes me nervous that the entire framework will stall due to unresolved questions around handling of metadata entry attributes by federation operators. However, as far as I can tell, the metadata entity attributes are only a hint for IdP discovery, and I understand the recommended practice is to list all eduGAIN IdPs in our discovery interface then gracefully handle errors rather than preemptively restricting the list of IdPs to only those with certain entity attributes.

Jim Basney
9Section 3.2

"The Identity Provider is trusted enough to be used to access the organization’s own systems." This cannot never be fullfiled by some organisations in Italy because they don't use SAML internally, so their IdP is used only to access external systems. At the same time all the identities managed by the IdP are trusted at the same level of the identities used to access internal systems.

Lalla Mantovani
10Section 2.4

Attribute freshness is also determined by the operational security of the IdP, which can have an impact on the LoA of the asserted attributes. We were wondering whether this should be added as a 5th point determining the overall LoA (i.e. as a 2.5). Section 3 point 4 mentions that "Generally-accepted security practices are applied to the Identity Provider." but this is too vague and still does not take operational security into account in the determination of the overall LoA. We feel that this could be made explicit by e.g. requiring SIRTFI for this baseline LoA.

 

Mischa Sallé & the rest of AARC-JRA1
1117, Sec 4, etcThe profile name "espresso" duplicates the name NISO ESPRESSO report, which is directly mentioned in the REFEDS discovery guide. This runs the risk of confusing service providers who might be referred to both the ESPRESSO report for discovery best practices and the espresso profile for assurance, and will be looking for both of these on URLs within refeds.org namespace. I know profile names were voted on (and indeed, I stupidly voted for espresso). However, I believe avoiding this confusion is a compelling reason to choose another coffee beverage.Guy Halse
12Line 44Proof-reading s/has/have/Andrew Cormack
13Line 88Or the SP could invoke some strong out-of-band process to verify whether the user is still the same? I'm thinking of courses that involve a student having a year in industry/another country, or academics taking sabaticals. Either of those could result in a year of non-use of a service. Or, indeed, there might be some services (e.g. enrollment) that are naturally only used once a year!Andrew Cormack
14Line 57-ishMaybe worth stating explicitly that none of the following applies to the identifiers actually listed under "unique"? "In addition to the three identifiers mentioned in the definition of "unique", within the REFEDS community..." and "... two additional values that a CSP declaring uniqueness can use to indicate the extent to which this applies to ePPN"Andrew Cormack
15Lines 177 & 186It bothers me that line 177 implies that Espresso is a superset of Cappucino, but the table in 186 says they aren't, The implication is that anything qualifying as "mfa" also satisfies "good-entropy", but I'd much prefer that (if it's true, which depends on what replaces the placeholders s2.3) to be handled explicitly by making good-entropy a requirement of Espresso as well (in the same way as you've done for the ranked IAP values)Andrew Cormack
16Line 51"authenticated sessions can qualify to different values." This possibility is not expanded on in the SAML representation section, only the entity level assertions are included.Hannah Short
17Line 65 - 78Should this be linked somehow to the Research and Scholarship entity category? R&S makes almost the same requirements on ePPN. Likewise, the fact that no ePPN reassignment properties are included in the capucchino and espresso profiles imply that ePPN should not be used (to my mind). I can imagine this being confusing when it comes to adoption by entities already using R&S.Hannah Short
18Lines 110 - 114The wording here is potentially misleading. Does "assert" mean comply with, or broadcast compliance with (e.g. in SAML metadata)? If they are incremental, is it really necessary to broadcast both?Hannah Short
19Line 164Given the lack of other "Generally-accepted security practices" in this domain, could we tie the framework to Sirtfi? +1 to Mischa's comment aboveHannah Short
  • No labels

3 Comments

  1. Petr Holub on behalf of BBMRI-ERIC - first draft, to be written better:

    • other attributes LoA: project affiliation from institutions - for projects that are given to the institution
      • when people are kicked out of the projects and still retain their institutional affiliation, we have no way to figure this out on the infrastructure level then their good will to report it back to us)
      • for projects given directly to the people (like ERC grants) this is not needed
    • another profile is common: verified identity (f2f) + passwords
    • authentication LoA: level for X.509 certificates - they are not necessarily multi-factor, depending on how they are implemented practically (token stored certs vs. browser-stored certs)
    • requirements on ID traceability need to be further specified, so that institutions can set up their policies properly: e.g., what happens if an institution goes out of business - with and without business continuity?
    • there might be even higher level of ID vetting/proofing LoA: when you validate the presented IDs with the government, and then even higher when you capture biometric information from the user as a part of the registration process. The latter one is not very likely for life sciences, but  the earlier might be needed to avoid problems with stolen/counterfeit IDs
    1. Hi Petr,

      token stored certs and browser-stored certs still both have an extra password (pin for token vs. keystore or browser master password). Only hostcerts typically don't. Are you thinking about a specific scenario?

  2. Fermilab is eager to use this feature.  We currently use CILogon Basic CA as our user certificate provider, and have begun to have problems with grid sites in Europe and Asia rejecting our certificates because they don't accept CILogon Basic CA.  Jim Basney explained to me that with this feature, assuming our IdP asserts the correct values, we will be able to get certificates from CILogon Silver CA which is accepted in Europe.

     

    My comment on the document itself is that it is difficult to understand what it is for at a high level.  It would be helpful to have a purpose statement at the beginning.