The initial 0.1 draft of the saml2int profile reformatted for Kantara is here. If you currently link to the old saml2int.org copy of this profile, you should revise your links because Kantara is the owner of the authoritative copy.
At present, active discussion to substantially revise saml2int is taking place within the InCommon Deployment Profile WG, which will make a set of change proposals to Kantara to revise this profile. This is expected by the end of 2017.
A first major piece of this work is a submission to OASIS to define a new identifier strategy for SAML, which we will propose as a required element of a new saml2int.
A set of older, largely historical issues identified are below.
...
Suggested Changes (mostly from older discussions amongst Ian/Scott/Andreas):
...
- Line 73, s/its metadata/their metadata
- Lines 91-93: no consensus yet on what to say here, but there are interop issues associated with not offering encryption keys even when TLS isn't used. This is one of the spots to revisit in light of recent events: replace with:
Each <md:SingleSignOnService> and <md:AssertionConsumerService> endpoint supported by an Identity Provider or Service Provider, respectively, MUST be protected by TLS/SSL.
- In section 6.1, line 150, several of us felt TLS should be a MUST for the IdP. Andreas hadn't responded on that question., change SHOULD to MUST.
- In section 7.1, replace lines 182-190 with:
The endpoint(s) at which a Service Provider receives a <saml2p:Response> message MUST be protected by TLS/SSL. If supported by an SP, Identity Providers MAY utilize XML Encryption and return a <saml2:EncryptedAssertion> element in the <saml2p:Response> message. The use of the <saml2:EncryptedID> and <saml2:EncryptedAttribute> elements is NOT RECOMMENDED; when possible, encrypt the entire assertion (if at all).
The <saml2:Response> element issued by the Identity Provider MUST be signed directly using a <ds:Signature> element within the <saml2:Response>. The <saml2:Assertion> element MAY also be signed directly if required for reasons other than the use of this profile.
- In section 7.1, replace lines 191-192 with "Service Providers MAY reject unsolicited <saml2p:Response> messages."
- In section 7.2, lines 197-198, reword as "MAY contain one <saml2:AttributeStatement> element".
...