RE: Shibboleth Use Case Supported?

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

Anders,

> > 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 think this is a very valuable option.  PKI is sometimes a bit scary.
> But there are a lot of interesting things between giving away your
> birth certificate and full anonymity.   The scenario I am mostly 
> interested in, OBI, is something in the middle: "This person, who we
> call J Doe is a representative for our [buying] organization 
> and he is licensed to shop"

We have no explicit requirement for anonyminity. (I can't prevent my
customer from creating an account called John Q. Public, but I am taking any
steps to hide the user's identity from the PDP.) If you see explict support
for anonymity as a requirement, I suggest you propose it.

> An helpful home-domain server will of couse alert the user if personal
> infomation is to be given out.  And since the credential 
> consumer is identified
> in the first place, you also have a pretty good idea where 
> this info goes.

Is this a requirement? How would this work? Is the home-domain server going
to call my cell phone?

> In the IETF-PKIX group I have "marketed" this as the X509 AC 
> killer and I see
> no signs of being wrong so far.

Well, I know YOU don't think you are wrong... ;-)

> > I am not sure, but I believe you assert that this message 
> exchange reduces
> > the need for advance configuration. I do not see that. 
> 
> You are absolutely right.  The "payload" must be agreed upon. 
>  But if your are
> let's say "OBI compatible", that does not require much more 
> than this declaration
> (in Purple(tm) there is even a Service Discovery Interface in 
> the works so you can see
> what your potential partner is capable of in terms of payloads).

I am sorry. After your other messages I studied up on Shibboleth. I don't
have time to study up on every protocol under development just to understand
your requirements. Would you please describe the salient features of OBI
that make it relevant to this discussion?

> What I have argued about is that S2ML v0.8 requires 
> configuration of certain
> low-level protocol pieces as well.  I.e. in spite of 
> agreement on payload,
> you must set a lot of partner-specific stuff.

I just don't see this. It seems to me both schemes require a lot of advance
knowledge of who your partners are, what your agreements are, what the
network addresses of various components are, etc. Where is the difference?

> > In Shibboleth it seems to me that arbitrary knowledge of 
> where to find the
> > user's home security domain must be configured in advance. 
 
> It sure is but it is on a rather high level.  Each usage will 
> dictate their own procedures.
> In B2B you may want to do a credit analysis on your potential 
> partner (not the user) more than anything else.

I can't tell if you are agreeing with me or disagreeing with me.
> 
> Shibboleth does AFAIK not support anything to support this in 
> a convenient manner.
> This is a part of my proposed extensions.

Proposed to whom? Where?

> > In general, I don't see what advantage this scheme has over 
> generating the
> > same credentials for a user every time. I feel you are 
> trying to solve some
> > specific problem, but I don't quite grasp its essential 
> characteristics.
> 
> I would say that Shibboleth solves a much broader class of 
> authentication/authorization
> problems than a system that only does one thing.

I agree it is more flexible, but unless you can specify a specific problem
that is being solved, that flexibility simply means more complexity.
 
> Hal, you are not a bit confused!  This was a nice and clear 
> specification. Coould'nt
> made it better myself. :-)

Thank you. I am gratified to know I understand WHAT you want to do, but I
still don't have a clue as to WHY you want to do it.

Hal