...
| Number | Line / Reference | Proposed Change or Query | Proposer | Action / Decision (please leave blank) |
|---|---|---|---|---|
| 1 | Section 2.2 | What about the other IGTF APs? Presumably CEDAR is also here if CEDAR>=BIRCH. What about ASPEN? (suggestion for Appendix) | Jens Jensen | |
| 2 | Section 2.1 | There 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 | |
| 3 | Section 2.1 | In 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 | |
| 4 | Line 166 | s/securitybcontacts/security contacts/ | Scott Cantor | |
| 5 | Section 4 | I'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 | |
| 6 | Section 5.1 | The overall assurance profiles really need to be handled via AuthnContextClassRef if you intend for RPs to be able to request their use. | Scott Cantor | |
| 7 | Section 5.1 | The 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 | |||
| 9 | Section 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 | |
| 10 | Section 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 | |
| 11 | 17, Sec 4, etc | The 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 |