An open discussion list for topics related to the eduGAIN interfederation service.

[Leif Johansson <leifj AT sunet.se>]

A few of us met at ACAMP in Indianapolis yesterday to talk about the
meta attribute work. I'll attempt to sum up and outline the plan that
we agreed on in the meeting:

Problem statement
-----------------

There are several policy framework in use today that rely on the use
of RequestedAttribute metadata elements to signal attribute requirements
from the SP to the IdP. This works well within federations but often
break down when an SP needs to talk to IdPs belonging to multiple
federations.

Experience from SPs that have begun to suck at the fire hose of
interfederation seems to be that as the number of federations grow, the
list of RequestedAttribute elements grow to the union of what is needed
to fulfil the recommendations and practice of all federations.

At best this violates the minimality principle and at worst causes
breakage since the RequestedAttribute practice of one federation is
often incompatible with that of the next federation. Experience shows
that breakage occurs after only a small number of connected
federations (I have example breakage at <3 federations).

The reason the problem occurs is that federations don't agree on the
semantic and use of attributes. Furthermore it seems unlikely that
we'll be able to align attribute semantics globally.

However we can introduce an additional level of indirection (which as
we all know solves any problem in computer science).

Proposal
--------

Introduce a new "meta" attribute NameFormat [1] with roughly the
following semantics:

When present in a RequestedAttribute element for instance like this:

<RequestedAttribute
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:meta" Name="foo" />

which requests release of the 'foo' attribute, the IdP releases one
or more "regular" oid-based attributes on the wire which corresponds
to 'foo' according to the accepted practice of the IdP.

Each meta attribute type (eg 'foo') will have its own spec that
describes the span of possible alternative ways it can be translated
to wire-format attributes.

For instance the 'name' meta attribute will probably be speced to
translate into something like "givenName & sn" and/or "displayName"
and/or "cn".

Under this scheme the SP will have to be able to handle a large
number of alternative ways to represent "name" but this is already
the case and is unlikely to change no matter what we do.

Next Steps
----------

0. Validate the idea with implementers. Scott seems to believe that
it is implementable in Shib 2 and 3. I have and AI to go and talk to
SSP and Roland will "cover" pysaml2 as usual

1. Do a writeup of the proposal and (probably) bring it to OASIS
for standardization as this is the recognized remit for SAML.

2a. Socialize the specification(s) among deployers and try to do
a pilot implementation within (say) Kalmar2.

2b. Take the spec to edugain-steering to get it adopted as the
way to do attribute management in edugain.

        Cheers Leif

[1] probably something like urn:oasis:names:tc:SAML:2.0:attrname-format:meta