RE: [security-services] Comment on sstc-saml-glossary-2.0 (also closes AI #0114)

[Scott Cantor <cantor.2@osu.edu>]

> The issue is that the request should match the semantics of the
> operation requested by the user and/or site.  So, for example, the user
> goes to a site which figures out the user is from a particular IdP (not
> saying how, but you can guess it is some form of a cookie) and the
> SP wants to use an existing federation, but it does not yet want to
> go to the point of establishing a federation if one doesn't already
> exist.

The SP isn't really affected either way, since he can throw the value away
even if the IdP does create it. The user obviously is affected and should be
able to tell the IdP "yes" or "no". I don't see how putting a value in a
request from the SP impacts the user's ability to do this. It seemed to me
to be a UI optimization to allow the SP to ask the question and tell the IdP
what the user said, which is why I phrased it as a consent distinction.

> I am very concerned about not being able to ask for an authentication
> without implying that I am also asking for a federation.  I think that
> people who are concerned with privacy would also be concerned about
> a protocl that does not allow that distinction.

Who is the second "I" in that first sentence? The SP, I assume? I'm not
seeing how I the principal am prevented from protecting my privacy if the
IdP honors my wishes. The SP can ask for a persistent value all it likes,
but that doesn't mean I'll let it have one.

In any case, I don't object to adding it or anything, but I was (months ago)
cognizant of the fact that such a flag is only relevant to one kind of SAML
NameIdentifier, and I wasn't sure what it added.

-- Scott