[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Proposed erratum resolutions
Ok, here are some proposed text changes for the PEs...(oh, and cheers to Adobe, Acrobat 7 makes copying text from PDFs so much easier now...) --- PE1: Relay State for HTTP Redirect [SAMLBind] Replace first paragraph of section 3.4.3 at line 545 with: "RelayState data MAY be included with a SAML protocol message transmitted with this binding. The value MUST NOT exceed 80 bytes in length and SHOULD be integrity protected by the entity creating the message, either via a digital signature (see section [3.4.4.1]) or by some independent means." --- PE2: Metadata clarifications A thorough disposition I think probably needs more review and especially more implementation experience, so it's a 2.x issue, but some small clarifications are suggested and then we can just move this to an issue for 2.x. [SAMLBind] Replace paragraph in section 3.6.7 at lines 1188-1191 with: "Support for receiving messages using the HTTP Artifact binding SHOULD be reflected by indicating URL endpoints at which requests and responses for a particular protocol or profile should be sent. Either a single endpoint or distinct request and response endpoints MAY be supplied. Support for sending messages using this binding SHOULD be accompanied by one or more indexed <md:ArtifactResolutionService> endpoints for processing <samlp:ArtifactResolve> messages." This is just intended to clarify that with artifact, the receiver is indicating support for the binding, while the sender is exposing a separate endpoint for resolving them. --- PE3: Supported URL Encoding This isn't actually an erratum, it's a missing piece that doesn't currently break anything but could in the future if alternate URL encodings for the Redirect binding emerge (for example a binary XML representation). We need an extension attribute to indicate non-default encoding support, it can just be added to our new "2.0 metadata extension schema". This should be moved to the issues list. --- PE4: SAML 1.1 Artifacts [SAMLBind] Add to line 1067: "Although the general artifact structure resembles that used in prior versions of SAML and the type code of the single format described below does not conflict with previously defined formats, there is explicitly no correspondence between SAML 2.0 artifacts and those found in any previous specifications, and artifact formats not defined specifically for use with SAML 2.0 MUST NOT be used with this binding." --- PE5: Rules for NameIDPolicy Probably needs more discussion in light of Brian's recent posting of other concerns about AllowCreate to saml-dev, but the erratum is specifically addressing transient. I see two options, the strict reading and the "common sense" reading. Either involves adding text after line 2147 of [SAMLCore]. Strict: "Finally, note that since the urn:oasis:names:tc:SAML:2.0:nameid-format:persistent Format value (see Section 8.3.8) implicitly results in a new identifier being created during the handling of most requests, the AllowCreate attribute MUST be set to true in order for such a value to be returned." Optimized: "Finally, note that since the urn:oasis:names:tc:SAML:2.0:nameid-format:persistent Format value (see Section 8.3.8) implicitly results in a new identifier being created during the handling of most requests, the AllowCreate attribute MUST be ignored by the identity provider when such an identifier is requested or issued." I favor the latter. I also agree with Brian that we need more guidance on what the point of AllowCreate really is. I think it's hard to separate it from the issue of "consent", personally, and might have been better handled with processing rules based on the Consent attribute, but that's water under the bridge. I do think the practical meaning of AllowCreate is potentially format specific, so it might be best just to acknowledge that. --- PE6: Encrypted NameID [SAMLCore] Append to paragraph ending on line 2139: "It is not possible for the service provider to specifically request that a particular kind of identifier be returned if it asks for encryption. The <md:NameIDFormat> metadata element (see [SAMLMeta]) or other out-of-band means MAY be used to determine what kind of identifier to encrypt and return." --- PE7: Metadata attributes WantAuthnRequestsSigned and AuthnRequestsSigned PE9: Clarification on SP AuthnRequestsSigned and the IdP WantAuthnRequestsSigned SP metadata flags I'll lump these together (Jahan, maybe combine them into a general "clarify metadata "signing" flags" or something like that). I'll take a lightweight approach to this by proposing text in the metadata spec rather than attacking the profile text with a lot of precise rules. [SAMLMetadata] Add text before line 710: "The WantAuthnRequestsSigned attribute is intended to indicate to service providers whether ot not they can expect an unsigned <AuthnRequest> message to be accepted by the identity provider. The identity provider is not obligated to reject unsigned requests nor is a service provider obligated to sign its requests, although it might reasonably expect an unsigned request will be rejected. In some cases, a service provider may not even know which identity provider will ultimately receive and respond to its requests, so the use of this attribute in such a case cannot be strictly defined. Furthermore, note that the specific method of signing that would be expected is binding-dependent. The HTTP Redirect binding (see [SAMLBind] sec XX) requires the signature be applied to the URL-encoded value rather than placed within the XML message, while other bindings generally permit the signature to be within the message in the usual fashion." Add text to paragraph at lines 741-742: "A value of false (or omission of this attribute) does not imply that the service provider will never sign its requests or that a signed request should be considered an error. However, an identity provider that receives an unsigned <samlp:AuthnRequest> message from a service provider whose metadata contains this attribute with a value of true MUST return a SAML error response and MUST not fulfill the request." Add text to paragraph at lines 744-747: "Note that an enclosing signature at the SAML binding or protocol layer does not suffice to meet this requirement, for example signing a <samlp:Response> containing the assertion(s) or a TLS connection." --- I guess others have actions to address some of the other issues. -- Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]