Shibboleth Developers

["RL 'Bob' Morgan" <>]

> Bob, I don't think what I suggested is "nuts" - complex perhaps but
> with a purpose.

Sorry, my use of that word was inappropriate, and I apologize for it.

> The "split identity" case was exactly why I suggested being able to
> use the same EPPN with 2 origin domains.  Within UC, for example,
> people have split appointments at multiple campuses.  I myself
> sometimes have to remember where I am connected in order to access
> certain services with the appropriate syntax.  I find it rather
> frustrating.  I certainly understand some of the complexity (e.g. my
> eligibilities may be the conjunction of several "origin site"
> definitions) so I don't suggest we bite off that chaw in the near
> term.  Longer term, I'd like to find a way to do it.

I agree that this is a problem that needs to be solved at some point.
SPKI (among others, perhaps, maybe X.509 PMI too) shows both how this will
probably have to work, and the practical challenges in making it actually
workable in the real world.  One could argue that Shib, to be useful, has
to deal with assembling assertions from many asserters in support of an
action, so we should design that in from the beginning.  I think the
evidence is that the world can (and desperately wants to) make good use of
single-asserter access control expressions today, and that trying to solve
the larger problem would delay us quite a while.  I'm hopeful that Shib
1.0 as proposed can evolve into the General Theory of Relationships as we
go forward (SPKI attribute certs as SAML AttributeValues, anyone?).

> Similarly with assertion origin versus security domains.  Maybe I, as
> a Relying Party, don't want to trust all those intermediate domains.
> By masking them, I am not even given the choice.  Again - I understand
> the complexity but I do think it may become important eventually to
> deal with this issue as trust models and systems increase in
> complexity.  For now, we just have to "trust" each entity along a path
> equally to do the right thing, not be hacked, etc.

Well, for those apps that care we can always provide the entire set of
assertions for their perusal.  But I continue to think that the majority
of apps and users want to use simple familiar attribute values, and want
"the infrastructure" to deal with the validity-assessment stuff.

> PS: I like your "semi-concrete example" that you sent this morning.

Thanks.

 - RL "Bob"


------------------------------------------------------mace-shib-design-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at 

    http://archives.internet2.edu/

------------------------------------------------------mace-shib-design--