Shibboleth Developers

["Scott Cantor" <>]

Major issues to touch on for tomorrow's call...

The draft attribute profile proposal is to leave be all currently assigned
eduPerson/inetOrgPerson/etc. attributes named as

urn:mace:dir:attribute-def:shortName

I guess the official list is here:
http://middleware.internet2.edu/urn-mace/urn-mace-dir-attribute-def.html

Any "new" attributes (eduCourseOffering/eduCourseMember) would be given
OID-based names.

The profile calls for all "scoped" attributes to continue to be bound to the
XML syntax we've been using to avoid interop problems with past versions.
This currently includes at least:

EPPN
eduPersonScopedAffiliation
eduCourseMember (new)

So far, this is "status quo" to minimize disruption. We do need to be very
precise about which "legacy" attributes are covered by the old naming, and
the eduPerson documents need to include all this new material.

eduPersonTargetedID is the outlier (and the real reason for the call). My
concern is that we sort of intentionally/unintentionally fell into using a
scoped syntax for this. I think this might have been because at the time, we
weren't exporting the IdP name into the environment, so scoping it was the
quick and dirty way to make it unique.

Subsequent to that, I was urging the major implementers to be sure and
combine whatever was in the exported attribute header with the
Shib-Origin-Site (now Shib-Identity-Provider) header. My hope was this might
insulate people from syntax changes.

There are basically three reasonable syntaxes (IMHO):

1- current (but the scope thing is kind of odd here)
<AttributeValue Scope="example.edu">98798hghgfsahgewueq</AttributeValue>

2- cleaner but has to be combined with the IdP name to be unique
<AttributeValue>98798hghgfsahgewueq</AttributeValue>

3- the syntax I'd like to use going forward, because it's explicit
<AttributeValue>
        <saml2:NameID Format="...persistent"
                NameQualifier="urn:mace:inqueue:example.edu"
                SPNameQualifier="https://sp.example.com/shibboleth";
         >98798hghgfsahgewueq</saml2:NameID>
</AttributeValue>

So there's the question of whether there's push back on the complexity of #3
(it requires code in the SP programmed to extract it), and there's the
question of how to export it.

And there's the question of whether to stick with 1, for compatibility
reasons, or go with 2 to avoid the scope mess.

The draft, which was only a straw man, uses an approach based on
distinguishing the old attribute-def name from the OID name and interpreting
the syntax based on that, allowing both an older legacy syntax and a newer
syntax to be used. But the newer syntax ought to match the "final" proposed
syntax for this in SAML 2.0. And it is a persistent NameID, so that's why I
figured it was best to just reflect that.

-- Scott