Attribute Encoders and Subjects and NameID/NameIdentifier in IdP V3

[Rod Widdowson]

This mail follows on from a note in the user list two weeks ago and a brief
conversation during the developers meeting last week.

Background:

The V2 IdP had two distinct mechanisms used to create a <saml:NameID> or a
<saml1:NameIdentifier>.   

In the first mechanism the attribute definition created the XMLObject and an
(effectively) no-op encoder prepared this object for encapsulating as an
<AttributeValue>.  See for instance the definition of eduPersonTargetedID in
the default distribution.

In the second mechanism the attribute definition created a string and a
specialized encoder put this inside the required XMLObject for encapsulation
in a <Subject>.

Having two different mechanisms was confusing, particularly since the
parameterization used different attributes ("nameIdFormat" vs "nameFormat")
and allowed different levels of control (you cannot specify a
NameIdSPQualifier) in the second  mechanism.

Additionally the two mechanisms were specifically targeted against different
parts of the Assertion.  The output of the first mechanism could not be used
inside a <Subject> and the output of the second could not be used inside an
<AtributeValue>.

Proposal:
In V3 we seek to simplify this situation.  The following is a proposal
(mostly for Scott, but others should feel more than welcome chime in) on how
to achieve this:

1) We favour the attribute definitions which create XMLObjects (NameID and
NameIdentifier) over the encoders which create them.

2) We deprecate (but still support in some manner or another) the second
mechanism.  That is the two encoders  SAML1StringNameIdentifier &
SAML2StringNameID will continue to work, but will not figure in our
documentation or our examples.  Using them may issue a warning.  We will
have no plans to remove support for them during the lifetime of V3.

3) We introduce two new name encoders which are no-ops (just as the encoder
in the first mechanism is) but which are used to create the identifier
required in the <Subject> statement.  

4) We change the distributed attribute-resolver.xml according to this new
pattern.  Thus the definition to use a transient attribute as the <NameID>
inside the <Subject> would become:

<resolver:AttributeDefinition id="transientId" xsi:type="TransientId"
xmlns="urn:mace:shibboleth:2.0:resolver:ad" dependencyOnly="true">

<resolver:AttributeDefinition id="transientNameId" xsi:type="SAML2NameID"
xmlns="urn:mace:shibboleth:2.0:resolver:ad"
        nameIdFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
sourceAttributeID="transientId">

   <resolver:AttributeEncoder xsi:type="SAML2NameID"
xmlns="urn:mace:shibboleth:2.0:attribute:encoder"/>
</resolver:AttributeDefinition>

With a similar derived attribute and encoder for SAML1.

This comes at the cost of an "extra" attribute definition, which I do not
think will be onerous, the more so that I would imagine that in some not
uncommon situations the current eduPersonTargetedID will be used as the
Subject NameID.

Thoughts?

Rod