Shibboleth Developers

["RL 'Bob' Morgan" <>]

On Mon, 16 Jun 2003, Walter Hoehn wrote:

> Since this is my last chance, I'm going throw up my hand here and admit
> that I don't really get this.

Well, we can agree perhaps that all these choices are painful, it's a
matter of choosing our pain.  I just see lots of confusion around
doc-based naming, and on the flip side I don't think documenting the
meaning of these minimalist URIs will be that hard.

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

  Attributes defined by EduPerson specification 2002/10
    (http://educause.edu/mumble/):

    urn:mace:dir:attribute-def:eduPersonAffiliation
    urn:mace:dir:attribute-def:eduPersonPrincipalName
    ...

  Attributes defined by X.520 (2000) as updated by RFC 2256:

    urn:mace:dir:attribute-def:cn
    urn:mace:dir:attribute-def:serialNumber
    ...

That way when the current docs change to EduPerson 2004/05 and RFC 3856,
we can update the refs on the registry page, but not have to change the
URNs or explain why an obsolete doc ref in the URN is "just a string".

> This being the case, what is so nasty about a naming scheme that groups
> things based on these same documents.

Because the current docs change.  To answer Scott's question of why the
docs change if the definitions don't, well, part of what permits the docs
to change (in the case of X.500/LDAP) is the the only true identifiers for
these objects are OIDs, so it doesn't matter what the exact document is.
It's certainly useful to update docs to clarify definitions of things over
time (as well as to add new features), as long as this doesn't invalidate
currently conforming implementations (clarification vs change can be a
fine line, of course).

> It seems to me that flattening the namespace makes things harder for us
> to manage (since we have to refer to external documentation for EVERY
> attribute, instead of groups of them)

Seems like our doc and refs can be structured however we want, as above.

> and less clear to users (something like "uid" could mean any number of
> things more or less specific than what is outlined in RFCs 1274/2798, do
> I really want to have to look at the registry to tell which sort of
> "uid" we are talking about here?).

Well, I'd say if uid is defined in multiple incompatible ways by docs that
might be considered to be authoritative, then it's pretty much unusable
out of the box.

As for looking at the registry for the precise definition, if it isn't
entirely clear from the referenced doc (eg in the case of EPPN and its XML
representation), I'd say yeah, this seems to me to be entirely natural.
Haven't we said often that it is the federation that defines the form and
meaning of attributes for use by federation participants?  Maybe you'd say
(and I might agree):  this def shouldn't be in the registry doc itself, it
should be in a separate doc.  But I still don't think that implies that
the name/url of that doc should be in the attr-def URI.

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