clarifying the "privacy" requirement

[RL 'Bob' Morgan <rlmorgan@washington.edu>]

Obviously based on discussion there is concern about having a requirement
for a "credentials negotiation" mechanism.  I think this discussion is
mostly out of scope while we talk about requirements, as it is mostly
about a mechanism that would be in support of some real requirements.  I
agree that a credentials negotiation mechanism is not so mainstream as to
be included in our basic architecture (alongside, say "signon" as a basic
element).

However, I continue to believe strongly that there is a requirement
related to "privacy".  It's one of a class of requirements that as far as
I can tell are largely unstated in our existing requirements, a class I
would call business-level requirements.  This also includes scalability,
and whatever it is that distinguishes the third-party security-provider
(scenario 3 in strawman 2) from, uh, first-party (scenario 1).  The
multi-domain/single-domain requirements are the only ones in this class
currently.  (About which more in another message.)

I think this requirement can be reasonably stated as something like:

  [R-Disclosure]  [OSSML] should support policy-based disclosure of
  subject security attributes, based on the identities of parties involved
  in an authentication or authorization exchange.

I think this is enough to satisfy the requirements that my system has to
meet (including US Federal laws about disclosure of student information).
It would, for example, exclude a solution that handed a user a bag of
attributes which would be passed on to any requesting service; we probably
aren't going to design something like that but I'd like to make sure.
This requirement doesn't say that anything about dynamic discovery of
policies, or real-time negotiation to support disclosure, or any of that
complex stuff that has some people worried.  So, can we agree on this
requirement?

I agree with Prateek's suggestion that issues about this requirement will
fall mostly into the "security considerations" area of our overall work,
since these issues are mostly about how the underlying mechanisms that we
provide will be used in particular deployments.  So I will respectfully
request the full group to change the name of that area to "security and
privacy considerations" to make that point.

 - RL "Bob"