...
# | Issue | Issue restated as requirement | Limitation | Relevant Profile Sections | Resolved |
---|---|---|---|---|---|
1 | Manual exchange of metadata or (worse) raw config into | Automated, ongoing metadata exchange and validation | Software/Operational | IIP-ME01, IIP-ME02 | Yes |
2 | Security risk/change control risk inherent in one-time MD exchange | Automated, ongoing metadata exchange and validation | Operational | IIP-ME01, IIP-ME02 | Yes |
3 | Lack of precise documentation and sloppy use of SAML constructs (in custom deployments) | More specificity for use of some specific SAML features | Software | Throughout | Yes |
4 | SP-initiated SSO as a "special" case | Support for SP-initiated SSO | Software | Not addressed | |
5 | Lack of deep link support | Support for deep linking | Software/Operational | Not addressed | |
6 | Use of frames that break with 3rd party cookies | Keeping authentication screens as top level windows (not iframes) | Operational | Not addressed | |
7 | Lack of dynamic provisioning/entitlement-like attribute based authZ | Support for attributes indicating group membership/entitlements (when customers handle authZ) | Software/Operational | Not addressed | |
8 | Lack of focus on AuthZ space and support | As above? | Operational | Not addressed | |
9 | Lack of clock skew allowance | Support for clock skew | Software | Not addressed | |
10 | Lack of encryption support | Support for XML encryption at the SP | Software | IIP-MA01, IIP-MA02, Section 2.5 (IIP-CA01 - 06), IIP-IDP11, IIP-IDP17 (maybe) | Yes; IDP17 is about support of saml:EncryptedID, not sure if it belongs here |
11 | Lack of key rollover support | Support for key rollover | Software | Section 2.1.3 (IIP-MK01, IIP-MK02, IIP-MK03) | Yes |
12 | Requiring valid (vendor signed and/or expiring) certs | Support for long-lived, self-signed certs, which may or may not be expired | Software/Operational | IIP-ME02, IIP-CE03 | Yes |
13 | Lack of discovery support/portable links (w/o hard coded IdP refs) | Support for discovery services | Software | IIP-SP07 | Yes |
14 | Hard coded 1:1 SP:IdP models | Support for multiple IdPs | Software/Operational | Not addressed | |
15 | Require non-opaque, non-transient NameID (rather than attribute) | Support for account identifiers in attributes (rather than NameIDs) | Software/Operational | IIP-SP02, IIP-SP06, IIP-IDP12 | Partial; SP requirements simply state "don't misuse persistent" and "don't include policy in AuthRequests". Do we need statement about not requiring NameIDs? |
16 | Requiring literal account IDs be asserted by IdP | Support for identifier mapping (i.e., IdP ID is mapped to an internal account ID) | Operational | Not addressed | |
17 | AuthnContextClass: not specifying at SP, but failing if PPT not used by IdP | Specify ACC; if unspecified, accept any ACC | Software | IIP-IDP10 | Partial; Addresses the requirement in a roundabout way. Does not state "must not require an ACC if it is not specified in metadata'. (Note clear that such a requirement would belong in this document, though). |
18 | AuthnContextClass: can't handle locally defined AuthnContextClasses | Allow support of extended ACC's (as part of site-specific configuration | Software | Not addressed | Possibly; arguably inferable from IIP-IDP10, but it is not clear from IDP10 that IdP must support arbitrary values for ACC. |
19 | AuthnContextClass: no "step-up" support | Support use of "step-up" authentication (re-auth with new ACC and poss ForceAuthn | Software/Operation | Not addressed | |
20 | Assuming Logout URL exists | Verify advertised IdP SLO endpoint before directing user there | Software | Not addressed | Partial; Says IdP must support, but does not indicate that SPs must honor IdP metadata. |
21 | Logoff handling | ??? | SAML | Section 4.5 (IIP-IDP15 - 17) | Probably |
22 | Expectations of SLO | ??? | Operational | Section 4.5 (IIP-IDP15 - 17) | Probably; (assuming this is largely a duplicate of issue 20 |
)23 | Browser cookie behavior impacting functionality (sessions not clearing, etc) | ??? | SAML | Not addressed | |
24 | Attribute release standards for IdPs | ??? | Operational | Not addressed | |
25 | Attribute release: suppressing grad students (FERPA concerns) | ??? | Operational | Not addressed | Is this and 24 about configuring conditional release of data from specfiic users? |
26 | Privacy practices: what is actually being kept private? | ??? | Tangential | Not addressed | |
27 | Standardized and effective workflow for dealing with attribute release | ??? | Operational | IIP-IDP04, IIP-IDP05, IIP-IDP06, arguably IIP-CE01 | Partial; IIP-IDP04 and 05 are useful for support of entity categories, and IIP-IDP06 is useful to the extent that including md:RequestedAttributes is part of the operational solution. IIP-CE01 is useful to the extent that consuming or excluding metadata simplifies the process |
28 | Vendors charging fees for setup and support of SAML | SAML support should be part of base service | Operational | Out of profile scope | |
29 | Lack of framework/contract terms; change controls, support escalation | ??? | Operational | Out of profile scope | |
30 | Lack of testing SP/IdP facilities (test SP, test IdP) | Run a testing SP/IdP for validation purposes during initial integration testing? | Operational | Not addressed | |
31 | Knowledge gaps with some vendors on how SAML works. | ??? | Operational | Out of profile scope or The entire document | |
32 | Advertised but unsupported functionality in metadata (artifact endpoints, etc.) | Advertise only supported endpoints | Operational | IIP-MA01; IIP-MA02 | Partial; MA01-02 address listed encryption profiles. Arguably the metadata exchange requirements imply support of this. But no specific requirement listed. |
33 | Availability of POP/mechanism for assessing risk | InCommon: stronger focus on POP? [May be addressed in different workgroups] | Operational | Out of profile scope | |
34 | Publishing metadata contact info for security incident response | Include security incident response (usually security or help desk) in metadata | Operational | Out of profile scope | |
35 | ForceAuthn: IdPs not ensuring user is reauthenticated | Verify function of reauth before resetting authninstant | Operational | Not addressed | |
36 | ForceAuthn: SPs not checking authninstant | Verify (or allow verification) of authninstant currency | Software/Operational | Not addressed | |
37 | OASIS Standards have not been updated with Errata, current Errata out-of-date | Recommend in report-out of WG that someone be resourced to update the Errata and a modify the standard to include the changes from Errata (working with OASIS) (Scott C says someone has informally volunteered to do this. Who?) | Standards | Out of profile scope | Yes; Addressed separately (Scott C, Eric) |
38 | Review with REFEDS once a solid draft is done | Nick to check in with Nicole on this | Standards | Out of profile scope | Nick |
39 | Research collaboration requirements for adoption of a persistent nameID | Use of persistent nameID or other mechanism to enable seamless collaboration across multiple SPs in a research organization. | Operational | Out of profile scope? | Scott K |
40 | "Ready For Collaboration" entity category for IdPs | Description of an entity category that would signal that an IdP is configured for ease of collaboration with no manual intervention by operators, does not re-assign ePPN, and/or uses persistent nameID... etc. TBD | Operational | Out of profile scope? | David W |
...