Attribute Encoders and Subjects and NameID/NameIdentifier in IdP V3

[Rod Widdowson]

[ As an update - I went back to the encoders as they are currently
implemented in V3 and for some reason I hadn't noticed that there is the
attribute encoder I had postulated, whilst there aren't any StringNameID
encoders, which would argue that the design assumed that we would grow the
required extra definitions during parsing - which I find slightly sleazy ]

> For a thought experiment, I'd like to suggest we think about simply
> getting rid of the concept of a NameID encoder, and instead just require
> that an attribute chosen for use as a NameID be, well, NameID-valued (or
> NameIdentifier-valued for SAML 1).

I had thought a bit about this (since I like the idea) and I had a few
questions:

1) Backwards compatibility.  Given the default setup and this paradigm we
would end up with both the TransientId and the eduPersonTargettedId as
candidates for the NameID, the former by legacy and the latter as per this
new design.   In this case we could choose to prefer legacy encoders over no
encoder.  

2) Which one to select?  Assume a new default with eduPersonTargettedId as
per now and TransientId as per my previous mail (but with no encoder), which
NameID do we chose to send in the Subject?  This would matter since we may
not have the PrincipalConnectors defined to handle all the possible NameIDs
we generate.

3) How do we supress sending a <NameID/> in a <Subject/>?   This may be a
stupid thing to do, but when I was kicking the wheels with V2 yesterday I
achieved this by supressing the encoder on the transientId.

Whilst these are not insuperable, they were enough to worry me.