RE: Shibboleth Use Case Supported?

[Hal Lockhart <hal.lockhart@entegrity.com>]

Bob,

> > Is that the essence of the approach?
> 
> Close enough.  I think there are two principles at work here. 
>  One is the
> basic security principle of least-privilege:  a target should be given
> what it needs to make its access-control decision, nothing more.  The
> other is user choice:  if I'm trying to access a target 
> resource and it's
> demanding to know a bunch of things about me in order to process my
> request, then I should be able to know what those things are 
> and refuse to
> play if I don't want to reveal them.  This is one definition 
> of "privacy".

Without committing myself on the merits of this approach, I will point out
that other more static approaches could be used to achieve privacy. For
example, a security domain could define a fixed (possibly per user) set of
"external" credentials or configure a per domain set of credentials.

> I recently ran across some work that both describes these concerns and
> some methods for implementing appropriate controls:
> 
>   http://www.transarc.com/~trg/TrustManagement/
>   http://www.pgp.com/research/nailabs/distributed/darpa00-trust.asp

Thanks, I will look at them.

> > I can see how this could provide flexibility, although the 
> unspecified
> > transformation in the middle worries me a little.
> 
> I don't see how this is any different from the interpretation 
> of privilege
> attributes by the receiving party, which is also "unspecified".

The difference is that the resource owner is the final authority. With
negoiation scheme we suddenly have this new error case that access should be
allowed, but the wrong credentials were provided. Mainly I am concerned that
standards are best at codifing current practice. Standards that break new
ground have historically less successful. That's why IRTF established
"experimental" RFCs.
 
> > I can also see how this enables anonymity (to the resource owner),
> > which is a Shibboleth requirement, but has not yet been tabled as a
> > requirement for this TC.
> 
> I wouldn't call our requirement "anonymity" which is both 
> rather slippery
> as a concept and not broad enough.  "Privacy" would be a better
> single-word shorthand, and "negotiated credential exchange" a better
> phrase.  And indeed I'm suggesting that it be a requirement 
> for this TC.
> I imagine that many of your customers are interested in this too.

Which? Privacy or credentials exchange specifically.

My main goal in the discussion was to try to discover a use case behind the
design.

Hal