Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

The initial 0.1 draft of the saml2int profile reformatted for Kantara is here.

Suggested Changes (mostly from older discussions amongst Ian/Scott/Andreas):

  • Add to section 3 after line 85:

    Any <md:RequestedAttribute> elements representing attributes to be exchanged using SAML 2.0 MUST have a NameFormat of "urn:oasis:names:tc:SAML:2.0:attrname-format:uri". Additional <md:RequestedAttribute> elements MAY be present if they are to be used in other protocols and include appropriate NameFormat values. The NameFormat attribute MUST NOT be omitted on any such elements.

  • Modify section 6.1, lines 147-148:

    Identity Providers MAY omit the verification of signatures in conjunction with this binding, and SHOULD NOT impose a requirement for signed requests. Identity Providers MAY support enhanced functionality in the presence of signed requests.

  • In section 2, the first three syntax examples use placeholder names while the last one uses a real element name. Should be made consistent. If we use the placeholder names, prefer ProtocolElement rather than Protocolelement.
  • Line 70, s/its entity/their entities
  • Line 73, s/its metadata/their metadata
  • Lines 91-93: 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, 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".
  • Extrapolate all required metadata content based on other profile requirements and explicitly enumerate those required elements. For example, since POST is a required binding for SPs, at least one ACS for that binding has to be present.
  • No labels