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

[Glenn Wearen <glenn.wearen AT heanet.ie>]

I think the ship has sailed on harmonisation so this proposal sounds good to 
me
Glenn

> On 29 Oct 2014, at 14:48, Leif Johansson <leifj AT sunet.se> wrote:
> 
> 
> 
> 
> 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
> 
> 
>