Attribute Encoders and Subjects and NameID/NameIdentifier in IdP V3

[Cantor, Scott]

On 4/30/13 11:00 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:

>[ 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 ]

I think it was based on the assumption they'd be removed. Remember that at
the time, we assumed compatibility would be achieved by config file
converters.

>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.  

None of this pertains to how NameIDs are selected. That's already an issue
in V2, and has a lot of messy solutions we use. That also needs to be
cleaned up, but that's a separate conversation.

>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.

Again, this is a separate matter and already affects the V2 system.

>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.

I would rather have an explicit control point to suppress this, then imply
it by the absence of an encoder.

-- Scott