Re: clarifying the "privacy" requirement

[George_Robert_Blakley_III@tivoli.com]

RL "Bob",

>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.)

Agreed up to this point

>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.

This seems inside-out to me.  I might have written

  [R-Disclosure]  [OSSML] should support *restriction of* disclosure of
  subject security attributes, *based on a policy stated by the subject*.
  *This policy might be* 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'm not sure.  I think I'm comfortable with including IN PROTOCOL BINDINGS
mechanisms for ensuring that security attributes aren't disclosed to anyone
but the recipient.  However I don't want to get into requiring encryption
of tokens, and I certainly don't want to get into trying to hide
security attributes from the recipients of the tokens.

>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.

I think this is a good suggestion.

--bob

Bob Blakley
Chief Scientist, Security
Tivoli Systems, Inc.