> I know, but I was hoping there'd be a smallish (finite) set of
> standardized, useful attributes, so that we could provide cooked access
> to those and raw to everything.
Depends who you ask. In current practice, the higher education community is
the only widespread user of the X.500/LDAP profile that was in the original
standard and tried to force people into compliance on naming anything you'd
find in a directory.
Implementers and deployers generally responded elsewhere with "that's nice,
we'll keep calling it 'displayName' thanks". This is mostly proportional to
the degree of scaling people are interested in. For us, federation is about
hundreds and thousands of sites, and for most vendors, it's usually about
two.
> Ah. I was thinking too of semantics, things like "hours that user may
> login" and so on, for which we could map to generic attribute syntaxes.
There aren't any standards for that anywhere that I know of. Basically
anything in LDAP or with an OID at least has *an* unambiguous SAML mapping.
Unfortunately, it's not the only such mapping, the cost of generality.
> Let's consider two options: the GSS-API cooks, versus the application
> cooks. In the first model you'd have to deliver plugins to the meghglue
> to cook new attributes, and you'd have to modify the application only to
> handle new "kinds" of attributes (new generic syntaxes). In the second
> model you'd have to modify the application only. The second model will
> always be feasible because we'll always provide raw attribute access.
>
> Which model is more attractive? I think that depends on how large a set
> of useful, generic syntaxes you can think of versus how many non-
> generalizable, useful/used attributes exist. If the latter dwarfs the
> former then I think the second model wins.
I don't think it does (the vast majority of attributes are string valued and
have no policy around them), but that doesn't take into account SAML
queries, for example.
-- Scott
|