> Difficult... A complete set would be difficult, but only because it'd
> be large. A useful set of "cooked" attributes (the alternative to raw)
> should not be too difficult.
What I meant by "cooked" is handling non-trivial syntax, policy-based
filtering that relies on SAML metadata, performing queries, that kind of
thing. If there's agreement to leave that kind of thing out of scope and
just support a direct mapping of SAML constructs to GSS name attributes, I'm
fine with that.
The "set" though is infinite, as there are no standard attributes in SAML.
You can't even count on URI naming, although I'm usually in favor of making
life painful for anything else.
> What kinds of SAML attributes are we talking about anyways?
Mostly the same kinds of things one finds in X.500/LDAP, but naming is a
pain in the ass because of some vendors that won some arguments I'd like to
go back in time and re-argue.
Identifying users/principals is also arbitrary, and one of the standard ways
of doing that isn't a simple string.
But that's all solvable. I'm just trying to work with Luke to draw the right
functional boundaries, so I know where my code does and doesn't contribute.
-- Scott
|