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.
