meta attributes (was: IdPv3 - eduPersonTargetedID - How to define and release this attribute?)

[Eric Goodman]

Behind on the list and thread hijacking (this isn't really a Shib question), but I still don't understand the logic of using meta-attributes.

>Right, but there's a tradeoff between what the SP is willing/able to 
>consume and what the IdP is willing/able to assert. If we ever get the 
>chance to do this again, we probably want to write the specification in 
>terms of meta-attributes. For example, an IdP that supports R&S might 
>be required to release a meta-attribute called "Shared User Identifier:"

><definition>

>Shared User Identifier

>FriendlyName: metaSharedUserID
>Name: http://id.example.org/attribute/metaSharedUserID

>A metaSharedUserID is a persistent, non-reassigned, non-targeted identifier.

>An Identity Provider (or Attribute Authority) is said to release a metaSharedUserID when it releases one of the following attributes on the wire:

How is this different than defining a new attribute "epSUID" and defining the contents in exactly the same manner? I understand that the tooling is different in terms of what's in meta data and what's released on the wire, but configuring an IdP to understand a meta attribute vs. configuring it to release a new attribute name seems about equivalent to me. 

If what you are discussing is an SP precedence filter (read ePUId, else read persistent nameid, else read....) that could be done without defining a new attribute type. 

But again, I'm not understanding the pragmatic difference between defining and supporting meta-attributes vs. defining a "new attribute type" given that either appears irrelevant if not understood and supported by the IdP. 

(n.b., on the definition: "persistent" in SAML speak really calls in the sense of "opaque" for per the definition of the nameid type. It's clear that you are not intending this; however this eventually gets defined I think it's worth making a note of that distinction). 

--- Eric