Shibboleth Developers

[Scott Cantor <>]

> but, the general description of the situation I'm now worried about 
> is "a set of criteria is used to determine whether a specific ARP 
> applies to the browser user; a second set specifies the set of 
> attributes and values that are released".

My point is that right now CMU has defined simplistically (but not
overly so, IMHO) everything as either a "User/Personal ARP" or a
"Default/Admin ARP". So the criteria is either "you own it or it's a
default".

If you wanted more than that, it could be implemented optionally later
on top of that by plugging in different code in the retrieval/matching
step to decide what ARP to return in the user case. Or you could
implement it on the other end of the process by expanding the criteria
statically and creating numerous user ARPs that apply to all the people
fitting the criteria. Usual static vs. dynamic tradeoffs of course.

> This actually sounds to me 
> a lot like the scenario we were using when describing "dynamic 
> attributes" (ie attributes generated by some plugin, after it did 
> some policy algebra). The policy algebra might be complex, and the 
> target site didn't want to assume the responsibility for the 
> computation. Additionally, the origin side didn't want to release all 
> the attribute values required for the computation.

That's very different in my mind. It's the (a) case I was trying to
eliminate. Deriving an attribute is just dynamically generating it
instead of statically storing it. Just like above, but it's on the "what
attributes belong to the user" side, not the "what gets released" side.

The usual reason for deriving the value itself at runtime is because the
technical or procedural overhead of storing it in the directory/database
is higher than the programming effort and cost at runtime.

Example: if you "own" or run the directory and the AA, the effort for
you to store and maintain something new in it may be small. But if I,
the AA maintainer, work for a different boss, and can easily derive the
value by writing some code that I control, it may be much less work than
getting you to add it to the directory for me. Umm, no comment on where
I got that example...

> So..... the 
> "generated attribute value" is different from all the attributes used 
> in the policy algebra computation. And maybe I'm describing an 
> attempt to provide a "general" mechanism to do this... and 
> over-reaching. Maybe I'm creating a GUI requirement for the AA, when 
> this was previously discussed, and we decided the site would have to 
> do some programming in the AA in order to accomplish this.

I don't think it's absolutely necessary to have that kind of advanced
policy matching to meet any near term use cases.

-- Scott

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

    http://archives.internet2.edu/

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