Shibboleth Developers

["RL 'Bob' Morgan" <>]

More hand-waving on this, hoping to crush all dissent ...

> > Are we planning to enumerate the semantics of all attributes in our
> > registry?  I wouldn't think so.  If we aren't, then we have to rely on
> > external documents to do so.
>
> Our attribute-def registry doc could certainly be structured like:

So, you might be saying, where's the line between "registry" and
"federation"?  That is, if attrs are named like:

>     urn:mace:dir:attribute-def:eduPersonAffiliation

that doesn't say "InCommon", or "InQueue" or anything (nor of course does
it refer to any eduPerson doc, but again I don't see that as a big deal).
At a high level we'd like a federation to say:  here are the attribute-
(types, defs, names) we're using, here's any details about why and what
and constraints and biz processes supported by them etc.  This is what
your http://www.columbia.edu/~wassa/profile/profile.html doc does.

But I think this kind of usage-specific profile, is (or can, or should be)
a distinct activity from registering an identifier for the attribute-def.
As I've mentioned, there is an odd little registry at IANA now that is
very similar to what we're talking about:

  http://www.iana.org/assignments/directory-system-names

As explained in section 3.8 of RFC 3383, this is actually an LDAPv2 thing,
and is to be replaced by a new improved larger-scope registry of
"descriptors" for LDAPv3, as specified in section 3.3 of RFC 3383, which
as far as I know doesn't exist yet.  But the point is that it's current
practice, for better or worse, for a registry like this to point at the
doc that specifies the registered thing (and as I mentioned this permits
the pointed-to doc to change as needed).  The IANA registries are all of
this flavor, I think, and I think reflect the fact that registration is
distinct from document-based definition.

Now it's certainly possible that we could choose to have InCommon be both
registry and profile-definer for these attribute-defs (that is,
urn:mace:incommon:attr-def:foo).  But here's InQueue, which we're now
characterizing as not even a flavor of InCommon but a separate thing.
Then there's all those other federations, many/most wanting to use the
same attrs we're defining.  So it seems reasonable to register these
attribute-defs in some neutral IANA-like spot.  For this (I suggest) we
choose the "mace-dir" activity, which I think is happy to cover not just
LDAP-y things but info definition in general.  So "mace-dir" can do Expert
Review (in the sense of RFC 3383)  of these attribute-def registrations,
and to reflect this authority we call the registry (as previously
proposed, I'm just justifying this choice):

  urn:mace:dir:attribute-def

Now we could think of IANA, and think of a MACE-managed IANA-like service,
which we might call something like

  urn:mace:mace-registry

which could in principle host all the kinds of registries IANA hosts.  I
guess I'm happy enough with the urn:mace:dir approach for now, and let the
need for more registries either move us to urn:mace:mace-reg, or establish
their own registry sub-arcs.  I don't think we'll have too much trouble
keeping track of what the MACE IANA-equivalent activities have authority
over.

When the Swiss, for example, define their own attrs they could either
establish their own registry and create the URNs there, or they could ask
the urn:mace:dir: registry to register their URNs (eg
urn:mace:dir:swissEduPerson).  We could then have a fine debate about
which is best, but either would work.  They'll have to have a doc saying
what those attrs mean in any case, and also something saying, for their
federation, what attrs and other stuff they will use.

So, the upshot is, in my opinion:

1.  There will be a registry page of attr-defs that will register the URN
and refer to the doc which defines the thing itself.  This will include
some of the material from your current profile.

2.  There's still a need for InCommon/InQueue attr profile.  In fact it
seems to me this should be part of other technical defs for these
federations, including audience URI, maybe assurance requirements, etc.
Policy about "you must make really sure this attr is true" could be here
too.

3.  There is the niggling issue of where the XML representation of EPPN
and EPSA are specified.  I think that this unfortunately requires a
separate doc, which would refer to eduPerson, and be referred to by the
registration of the URNs for these attr-defs.  Perhaps a future revision
of eduPerson could include this, alongside the LDAP syntax defs.

So that's my story and in my current state of mind it makes as much sense
as anything else, so I'm hopeful it's persuasive enough that we can decide
finally to go with the urn:mace:dir:attribute-def URN format.

 - 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--