...
| # | 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-ME01MD03, IIP-ME02ME04 | Yes |
| 2 | Security risk/change control risk inherent in one-time MD exchange | Automated, ongoing metadata exchange and validation | Operational | IIP-ME01ME03, IIP-ME02ME04 | 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 | IIP-SSO01 | Yes |
| 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-MA01SSO04, IIP-MD09, IIP-MD10,IIP-MD12, IIP-MA02MD13, Section 2.5 (IIP-CA01 ALG01 - 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-MK01MD06, IIP-MK02MD07, IIP-MK03MD08) | 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-ME02MD04, IIP-MD11, IIP-CE03MD13 | 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 require nameid policy in AuthRequests". IdP says "don't require NameID in assertion". Do we need statement about SP accepting assertions not requiring containing 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) | SoftwareNot addressed | See Issue 18 | 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 | SoftwareNot addressed | Section 4.5 (IIP-IDP15 - 17) | Partial; Says IdP must support, but does not indicate that SPs must honor IdP metadata. Do we need an SP requirement here? |
| 21 | Logoff handling | ??? | SAML | Section 4.5 (IIP-IDP15 - 17) | Probably |
| 22 | Expectations of SLO | ??? | Operational | Section 4.5 (IIP-IDP15 - 17) | ProbablyPartial; (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-CE01MD03 | 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 MD03 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-MA01MD09; IIP-MA02MD10 | Partial; MA01-02 address listed encryption profiles. Arguably the metadata exchange requirements imply some support of this. But , but no specific requirement requirements are 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 |
...