> My position there is that you want a mechanism for making unfiltered
> attributes available to an application, but you also want a mechanism
> for making the filtered information available if you have sufficient
> local policy (or policy you got from somewhere like metadata) as well.
> It's absolutely critical that an application knows whether it is asking
> for filtered data--data that someone has made a trust decision about--or
> raw data--data it needs to decide the trust level of itself.
That distinction hasn't come up, or at least hasn't been made, because the
existing systems can't really accept "raw" assertions. You have to have
metadata, a way to verify the signature, etc. Local filtering policy is then
whatever you choose to make it.
> ASM would meet the use case I described even if it didn't support
> getting this information to an SP because AAA also doesn't support
> getting that information to the SP, so we'd be as well off as if we just
> sent a full assertion in the RADIUS request or used RADIUS attributes
> directly. ASM would be a complete failure in my mind if it got in the
> way of you using this sort of filtering metadata when you have it. (I'm
> not fond of security mechanism that break other existing mechanisms.)
Yes, I can see that. As you say, this is something we need to be able to
distinguish at runtime.
-- Scott
|