[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services-comment] Invitation to comment on SAML V2.0 Subject Identifier Attributes Profile V1.0 - ends Dec. 12th
Subject: Comments re SAML V2.0 Subject Identifier Attributes Profile Version 1.0 http://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/csprd01/saml-subject-id-attr-v1.0-csprd01.pdf ----- Substantive Issues and Suggestions: [section 3] Suggestion: For clarity, group all processing requirements (for the relying party) in a single subsection (or at least in contiguous paragraphs). For your convenience, here is a list of all processing requirements AFAICT: lines 117--118 lines 132--134 lines 145--147 lines 153--156 lines 183--185 lines 195--195 [line 86] The usual prefix is: urn:oasis:names:tc:SAML:2.0:profiles Suggestion: urn:oasis:names:tc:SAML:2.0:profiles:subject-id [lines 98--101] The word “entityID” implies the use of metadata and therefore the use of that word in these definitions is problematic. I suggest you eliminate the use of this word altogether. AFAICT, it’s not needed in this spec. [line 102] The term “Service Provider” is undefined. [line 104] The term “Identity Provider” is undefined. [section 3.3] Suggestion: Add an explicit example of a <saml:Attribute> element to the latter part of this section. [line 107] The term “Standard Subject Identifier” does not adequately describe the identifier being defined in this section. Both of the identifiers defined in sections 3.3 and 3.4 are “standard.” [line 109] The usual prefix is: urn:oasis:names:tc:SAML:2.0:profiles:attribute [line 109] The suffix “subject-id” is suboptimal for two reasons: 1) the suffix clashes with the suffix of the identifier on line 86, and 2) the identifier defined in section 3.4 is also a subject identifier. [lines 109--110] What is the FriendlyName of this Attribute? (Deployers will invent a FriendlyName if you don’t.) [lines 114--116] This is a binding rule, not a syntax rule. This requirement is out of place. [lines 114--116] Add a binding rule that begins with the following text: “This Attribute, when appearing as a <saml:NameID> element...” [line 117] Define “whitespace.” What characters exactly should be stripped? [lines 117--118] More importantly, what is the corresponding binding rule for the asserting party? [line 128] A normative reference for “ABNF grammar” is needed. As it is, the primitives ALPHA and DIGIT are undefined. [lines 132--134] The importance of this requirement is underemphasized. In the following subsection, the word “value” really means “equivalence class of values.” All values in an equivalence class are bound to at most one subject. The following paragraph attempts to make this precise: Let V1 and V2 be any two values recognized by the grammar. The two values are equal if and only if lowercase(V1) === lowercase(V2). Any two such values belong to the same equivalence class of values. All values in any given equivalence class MUST be bound to the same subject (or none at all). [lines 157--158] Convert this sentence into a normative requirement for asserting parties. [section 3.4] Add an explicit example of a <saml:Attribute> element to this section. [line 161] The usual prefix is: urn:oasis:names:tc:SAML:2.0:profiles:attribute [lines 161--162] What is the FriendlyName of this Attribute? (Deployers will invent a FriendlyName if you don’t.) [lines 181--182] The word “reversible” implicitly refers to a hashed value. As you know, not all pairwise identifiers are hashed values, but for the sake of discussion, let’s assume it is. Is the use of SHA-1 allowed? [line 191] The term “Identity Provider” is undefined. [line 192] The term “Service Provider” is undefined. [lines 210--211] If a relying party requests a long-lived, non-reassigned identifier from an asserting party (by whatever means), but the asserting party asserts the legacy SAML V2.0 Persistent Identifier in lieu of the subject identifiers defined in this specification, is the asserting party conforming to this specification? [section 3.5.1] The requirements in this section say nothing about the relevant role descriptor(s) in metadata. I assume an SPSSODescriptor is required, but in that case, what if there are multiple AttributeConsumingService elements in that role descriptor? Speaking of which, the AttributeConsumingService construct was invented exactly for this purpose, so I’m not sure why you’ve profiled the use of an entity attribute? Suppose a relying party issues an AuthnRequest containing a <req-attr:RequestedAttributes> extension element. How does the relying party signal its identifier requirements in the AuthnRequest? Similarly, suppose a relying party issues an AttributeQuery containing one or more <saml:Attribute> elements. How does the relying party signal its identifier requirements in the AttributeQuery? The signaling mechanism profiled in section 3.5.1 does not address these questions. It seems we need a general-purpose signaling mechanism that satisfies all of these use cases. [lines 248--251] If the Attribute is carried in a <saml:NameID> element, is the asserting party conforming to this specification? (I assume that it is, but in any case, the spec should be explicit so that conformance is understood, one way or the other.) [lines 252--252] It looks like [SAML2Prof] is normative. (It is listed as a non-normative reference on page 6.) [lines 258--259] It never occurred to me I was reading an implementation profile until I got to this page. Instead of defining conformance in terms of the implementation, I’ll suggest that conformance align with the semantics of the following metadata elements: md:IDPSSODescriptor/md:AttributeProfile and md:IDPSSODescriptor/saml:Attribute. In any case, consider the following replacement text: An asserting party conforms to this specification if all of the following statements are true: If the asserting party asserts the Attribute defined in section 3.3, then the asserting party MUST satisfy all of the relevant requirements in section 3.3. If the asserting party asserts the Attribute defined in section 3.4, then the asserting party MUST satisfy all of the relevant requirements in section 3.4. The asserting party MUST support at least one of the Attributes defined in this specification. An asserting party that conforms to this specification MAY carry the relevant md:IDPSSODescriptor/md:AttributeProfile element in its metadata. It MAY also carry one or more md:IDPSSODescriptor/saml:Attribute elements in its metadata. [lines 261--263] Again, it doesn’t really make sense (to me) to define conformance in terms of the implementation. [lines 264--265] This requirement focuses on just one of three possible use cases (listed above). I believe a more general signaling mechanism is needed. ----- Minor Typos and Suggestions: [Abstract] s/SAML persistent NameID format/SAML V2.0 Persistent Identifier/ [line 23) s/supply/issue/ [line 38] s/Identifiers should be as stable as possible and should never have a risk of reassignment/Long-lived identifiers should be as stable as possible and should have little or no risk of reassignment/ [lines 44--45] s/enforce policy around the issuers permitted to supply an identifier/enforce policy stipulating the asserting parties permitted to issue an identifier/ [line 64] s/For all these reasons/For all of these reasons/ [line 64] s/using/by taking/ [line 68] s/Clean slate notwithstanding/A clean slate notwithstanding/ [line 74] s/the eduPersonTargetedID attribute/the related eduPersonTargetedID attribute/ [line 92] s/generally but not exclusively people/which are generally but not exclusively people/ [line 94] s/Attributes/SAML Attributes/ [line 94] s/LDAP/LDAP subjects/ [line 95] s/mapped to and form/mapped to and from/ [line 108] s/standard identification of subjects/general identification of subjects/ (?) [line 111] s/non-re-assignable/non-reassignable/ [line 111] s/suitable as a globally-unique external key/suitable for use as a globally unique external key/ [line 112] s/ by applications./. Its value for a given subject is independent of the relying party to whom it is given./ [line 124] s/typically may be/typically is/ [line 136] s/A value/Regardless of the relying party, a value/ [line 136] s/only one subject/one and only one subject/ [lines 145, 148, 183, 186] s/should not/SHOULD NOT/ (?) [lines 150--151] s/and for which relying parties/or the relying parties/ [line 157] s/may be identified/MAY be identified/ (?) [line 163] s/non-re-assignable/non-reassignable/ [line 163] s/suitable as a unique external key/suitable for use as a unique external key/ [line 164] s/to particular applications/by a particular relying party/ [line 164] s/depends on/depends upon/ [line 165] s/preventing/thus preventing/ [line 202] s/reproducible values/values/ [line 203] s/specific approach,/specific approach/ [line 224] s/authentication profiles/single sign-on profiles/ [line 224] s/the Browser SSO and Enhanced Client and Proxy profiles/the Web Browser SSO Profile and the Enhanced Client or Proxy (ECP) Profile/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]