...
- 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.2, lines 197-198, reword as "MAY contain one <saml2:AttributeStatement> element".
...