OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[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]