Re: clarifying the "privacy" requirement

[Anders Rundgren <anders.rundgren@telia.com>]

Bob * 2,
I read this with great interst.  I was just going to post a message with functionally
identical comments to that of Bob M's!

My question seems remaining hanging: How can you actually create a practical, useful, maintainable,
extensible, privacy/information disclosure mechanism without turning to credential negotiation?
I know we are the Use Case group, but some kind of background design must be performed in parallell
in order to not produce use cases that does not work or breakes away from the anticipated path.

At least it would be interesting to hear how Shibboleth is going to handle this, in spite of Shibboleth
functionality being a non-goal (it is?).

I did not bring up this on the tel-con as I feel that a written pro/con document is needed to
get this anywhere close to a voting.  Unfortunately I don't think I will make the F2F where
this should be discussed as it is of the same magnitude as sessions.

Anders

----- Original Message ----- 
From: "RL 'Bob' Morgan" <rlmorgan@washington.edu>
To: <George_Robert_Blakley_III@tivoli.com>
Cc: "OASIS Security-Use List" <security-use@lists.oasis-open.org>
Sent: Wednesday, February 14, 2001 10:23
Subject: Re: clarifying the "privacy" requirement


> 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"
> 
> 
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: security-use-request@lists.oasis-open.org