Attribute Encoders and Subjects and NameID/NameIdentifier in IdP V3

[Cantor, Scott]

On 5/1/13 6:15 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:

>What we are saying is that in V2 encoders and their configuration language
>actually have two different jobs:
>
>1) To encode attributes up in a manner which is suitable for inclusion in
>a
><saml:Attribute/> or whatever is apposite for the underlying protocol.
>This
>is non controversial.
>2) To signal whatever is building the <saml:Assertion/> that "this one
>here
>is the <NameID/>

Well, it's to signal that it *can* be a NameID. Which one becomes the
NameID is a complex web of options involving metadata of both IdP and SP,
the new nameIDPrecedence thing in relying-party.xml, and the initial
release of attributes.

But, yes, there's a specific dedicated encoder type for
NameID/NameIdentifier, separate from the ones that do Attribute.

>In V3 we really want the encoders to concentrate on the first.

I do, I think.

>For the second the current mechanism is not sufficient/confusing/wrong and
>we need to develop something else which gives us the control we need,
>while
>respecting backwards compatibility (I don't think this last need be as
>terrifying as I thought it was)

We may have to provide the old stuff, but I think if we code the NameID
generation action to handle either NameID-valued IdP Attribute objects, or
the legacy encoder types, we can at least deprecate the old stuff.

-- Scott