Re: clarifying the "privacy" requirement

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

Bob:

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

Well, I would have thought that "policy-based disclosure" implies
"disclosure restricted by policy rules", but sure, I can clarify that.

Your phrase "based on a policy stated by the subject" I find very
puzzling.  Surely where policy comes from differs greatly depending on the
situation.  In a consumer/ISP scenario it might be "stated by the
subject", meaning the end-user.  In an institutional scenario (eg
university users accessing a publisher, our standard Shibboleth scenario)
the policy might be determined by contracts between the parties, with some
end-user choice.  In a military setting (eg a defense contractor accessing
a Pentagon web site for weapons plans) it might be determined entirely by
written regulations (access requires security clearance info, etc).  Why
would we want to specify who sets the policy in this requirement
statement?

>   *This policy might be* based on the identities of parties involved

Right.  The point is that the identities of the parties involved be
available, if required, for use in making the policy decision, not that
it's always based on that, or only on that.

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

Here you are thinking about "disclosure" in the sense of "disclosure to
eavesdroppers" (hence requiring confidentiality protection of the
attribute assertion); and I think you may also be thinking about
content-protection-style controls where portions of assertions are
selectively encrypted, to support the same assertion passing through
multiple hands but revealing different portions to each.

I have to admit I was not thinking of disclosure in this low-level sense
but rather in the sense that policy should be able to control
what attributes get put into an attribute assertion.  While I think your
response here is mostly inappropriate because you're talking not about the
requirement itself but your opinions of what mechanisms would be needed to
support the requirement, I will try to recast it to make more clear that
the intent is not to require complex crypto.

 - RL "Bob"