Re: [security-services-comment] Invitation to comment on SAML V2.0 Subject Identifier Attributes Profile V1.0 - ends Dec. 12th

[Tom Scavo <trscavo@gmail.com>]

Here are some followup thoughts on this subject before the public
review period ends.

First of all, the email addresses on this official page are in error:

https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=security

I don't know if that error is preventing people from commenting but I
wanted to point that out.

I raised a number of questions last time but did not attempt to
provide any answers. I'll try to be more concrete this time. Hopefully
this will prevent multiple iterations.

Basically, I'm not convinced that two identifiers are needed. Any use
case I can think of can be handled with a single identifier (and
entity attributes). I wrote up four use case descriptions (see
attached PDF) that show how far you can get with a single identifier.
The use cases illustrate:

- one new identifier (SAMLUniqueID)
- support for md:RequestedAttribute (which is essential)
- implicit support for SAML Affiliation

The latter is achieved by the use of so-called entity categories. The
entity attribute value in SP metadata can be used by the IdP to limit
the scope of the identifier to the category. AFAIK, this can be done
today with current SAML technology so I'm not sure why the entity
attribute in section 3.5.1 of the draft is needed.

Thank you for considering my comments on this important spec.

Tom


On Mon, Nov 20, 2017 at 11:05 AM, Tom Scavo <trscavo@gmail.com> wrote:
> 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/

Attachment: SAML Unique ID.pdf
Description: Adobe PDF document