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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Public Comment


Comment from: dave.mcalpin@epok.net

Here are some comments on the public review version of Assertions and Protocols from the perspective of a naive outsider. Note that I skipped section 3 and just skimmed sections 8 and 9.

- Line 314. I assume the requirements here apply not just to pseudorandom numbers but also to true random numbers.

- Line 357. Schema shows elementFormDefault="unqualified". Since all types are declared globally I don't think the value for elementFormDefault even matters, but "unqualified" is pretty misleading since all elements in an instance document end up namespace qualified, donít they?

- Line 386. Typo. Drop "need".

- Line 435 - The default for format on line 435 is contradicted by line 490, where a different default is defined for Issuer. Maybe 435 should start "If no Format value is provided and no default is otherwise defined, the value...".

- Line 468 says "The encrypted content MUST contain an element that has a type that is derived from BaseIDAbstractType, NameIDType or AssertionType." I was confused by "derived from"; it makes it sound like an element with a type of NameIDType, for example, wouldn't satisfy the requirement. Maybe something like, "The encrypted content MUST contain an element that either a) has a type of NameIDType or AssertionType or b) has a type that is derived from BaseIDAbstractType, NameIDType or AssertionType. Similar comment for line 591 / AssertionType and line 1181 / AttributeType.

- Line 469 - The fact that the content of an EncryptedID can be an assertion is surprising. What does it mean to use an assertion as an identifier? Is the assertion's subject the thing identified? If using an assertion for an identifier is useful, why isn't it allowed in unencrypted form?

- Lines 475 to 477. This is a judgment call, but I think the MUST here is too strong. To me this seems like a desired feature rather than an absolute requirement for interoperability or operation. Maybe this could be expanded a little and changed to a normative SHOULD, like "Encrypted identifiers are intended to provide privacy protection when identifiers pass through an intermediary. If the ciphertext that results from the encryption of an identifier is the same each time a particular identifier is encrypted, certain aspects of privacy may be compromised. For this reason, an encryption algorithm SHOULD be chosen that insures the ciphertext is unique for any given encryption operation. For more on this and related issues, see [XMLEnc] ß6.3."

- Line 504. First, "resolving" is a confusing word to use with URIs, since 2396 and 2396bis both use "resolve" to mean, roughly, "take a relative URI and make it absolute". Second, must it _always_ be possible to retrieve the assertion via the AssertionURIRef, or is it legal for the URI reference to identify the assertion without necessarily providing a means of retrieval? I'd suggest it should be legal to simply identify. If that's the case, I'd just remove the sentence that begins "Resolving a URI reference..." and leave it to the binding or profile to describe the operations (like retrieval) that can be performed on the referenced assertion.

- Line 532. Normative MUST is confusing, since Conditions are required to be "taken into account" but there's no guidance for dealing with an assertion that turns out to be Invalid or Indeterminate. What's the conformance test for "taken into account"?

- Line 549. The line that starts "If omitted..." is confusing for a couple of reasons. First, I think statements "apply to" subjects rather than "identify" subjects. Second, if there's no subject, then the subject is implicit by definition, isn't it? I'd change that line to "If <Subject> is omitted, then the statements in an assertion apply to a subject or subjects as identified in an application- or profile-specific manner."

- Line 561. Normative MAY seems odd. A "relying party" gets a SAML assertion. It's signed, so he MUST validate the signature. The signature is valid, so he SHOULD look to see who signed it (but no guidance about correlating the signer and the issuer). That done, the relying party "MAY process the assertion in accordance with this specification and as it deems appropriate". Is it really true that interoperability and operational requirements end with signature validation? At a minimum, isn't the relying party required to evaluate the Conditions block, the version, required elements etc.? I'd just drop the "MAY process" clause and possibly give some advice about making sure the signature was applied by the expected signer.

- Line 682 and 687. I was stumped by the intent of Recipient and Address in SubmectConfirmationData until I looked at the example for Bearer in Profiles. I think these could both use a little elaboration. I may have this wrong, but my understanding for Recipient is that it "Specifies the entity or location to which an entity can present the assertion while confirming itself. In other words, confirmation of the subject can only be performed by the entity or location identified by the URI in this attribute." For Adress, "Specifies the network address from which an entity can present the assertion while authenticating itself. In other words, confirmation of the subject should only be performed if the assertion was obtained from the network address identified by the URI in this attribute."

- Lines 790 to 808. The rules for evaluating Conditions appear to contradict the text that follows. From rules 2 and 3 it seems like an invalid condition has a higher priority than an indeterminate condition. The text that follows, however, makes it sound like an indeterminate condition has a higher priority than an invalid condition. I'm not sure, for example, whether an assertion that contains both an invalid condition and a condition that's not understood is Invalid or Indeterminate. Applying the rules in order, I think, would make it Invalid, but it seems like the text that follows requires it to be Indeterminate.

- Lines 816 - "and if any other conditions" should be "and if all other conditions". Same comment for line 820.

- Lines 849 to 850 are interesting. If there are two AudienceRestriction elements and I'm included in one but not the other, I should consider the assertion Invalid. Another way of looking at it is that multiple Audience elements within an AudienceRestriction are OR'd, while multiple AudienceRestriction elements are AND'd. I suppose that could be useful, but it should probably be called out a little more explicitly in the text.

- Line 904. The "MAY" here does not have the meaning defined by 2119. It should appear in lower case. Same comment for line 907.

- Line 995 - 996. "Contains a reference to an authentication context class, an authentication context declaration, declaration reference, or both." I didn't understand this until I read the equivalent description on line 1045. I'd follow the form there, and say "Contains a reference to an authentication context class, an authentication context declaration or declaration reference, or both."

- Line 1000. The "MUST NOT" says this is an absolute prohibition of the spec, but it only applies "when privacy is a consideration". In my opinion, the phrase "when privacy is a consideration" is way too underdefined to support a normative "MUST NOT". I'd drop the caps there. The "RECOMMENDED" on line 1002 is fine.

- Line 1118 - Typo. attname-format should be attrname-format

- Line 1293 - "contains an assertion or assertion reference" should be "contains one or more assertions or references to assertions"

Skipped section 3

- Line 2609 - Boolean algebra symbols are impressive, but OR and AND would be much more accessible to a general reader.

- Line 2700+ - This may not be a contradiction, but I found it confusing. Lines 2633 and 2653 say "There is explicitly NO relationship between the assertion [or protocol] version and the target XML namespace specified for the schema definitions for that assertion [or protocol] version." Line 2700, however, says, "The major and minor version in the URI MUST correspond to the major and minor version of the specification set in which the namespace is first introduced and defined" and goes on to say that this "is intended to communicate the relationship between the specification set and the namespaces it defines."

- Line 2775 - Some of the rules in the XML Signature Profile seem to contradict lines 2770 - 2774. For example, Line 2785 says, "SAML assertions and protocols MUST use enveloped signatures when signing assertions and protocol messages." Line 2700+, however, makes it clear (at least I think it's clear) that a SAML Assertion is allowed to inherit a detached or enveloping signature if a profile says it's ok. In addition, line 2754 explicitly allows a profile to define an alternative to enveloped signatures. Maybe you just need a sentence in section 5.4 that says this XML signature profile only applies to signatures that appear inside a SAML assertion, a SAML request or a SAML response, and the rules may be overridden by a SAML profile. 

- Line 2793 - Is an example of using a relative reference (#foo) sufficient to override the requirement in section 1.2.2 that all URIs must be absolute?

- Line 2825 - xmlns:samlp is never used. If you remove it, also drop it from lines 2837 and 2888.

- Line 2877 - Typo. Drop double quote at the end of the URI. Also, namespace qualifier is redundant because default namespace is already urn:oasis:names:tc:SAML:2.0:assertion.

- Line 2980 - "how to define new profiles of use" - drop "of use".

- Just an FYI on 2396bis. The notion of "absolute URI" changes somewhat in RFC2396bis in that it doesn't allow a fragment. When that spec officially obsoletes 2396, line 295 will need to change to something like "and are REQUIRED to match the URI production defined in [XXXX]."  Line 1200+ will also be affected since RFC2396bis has much more to say about equivalence than RFC2396 did.

Dave McAlpin



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]