My earlier answer which I only sent to Sam said essentially that the
questions he was asking all related to the trustworthiness of the IDP,
and were not to do with semantics. Given that there is an adequate
definition of the unique identifying attribute that is needed (and
this covers the semantic issues), then the RP has to trust the IdP to
abide by these rules. If the IDP cannot be trusted, then dont use it.
Its as simple as that (you cannot trust an untrustworthy entity). If
the RP want re-assurance that the IDP can be trusted, then you have to
instigate some sort of validation mechanism such as certification or
audit. But dont mix up trust and semantics

David

On 22/04/2014 18:59, Stefan Winter wrote:
> Hi,
> 
>> We are not in agreement on this issue. I believe that several
>> factors relating to the semantics of the attribute are critical
>> for access control decisions.  Examples include:
>> 
>> * Temporal uniqueness of the identifier
>> 
>> * What precautions are taken to avoid re-use
>> 
>> * Uniqueness across events such as name changes, marriage,
>> affiliation changes (student becomes staff)
>> 
>> It's not clear to me that the answers that the broader AAA
>> community has given for CUI are entirely match what we're looking
>> for.
>> 
>> --Sam
> 
> I don't really see a disconnect here. Looking at the
> eduPersonTargetedID definition: it starts from a SAML definition
> which is rather vague regarding re-use. From [1]:
> 
> "As defined by SAML, eduPersonTargetedID values are not required to
> have a specific lifetime, but the association SHOULD be maintained
> longer than a single user interaction and long enough to be useful
> as a key for consuming services."
> 
> Which is *surprisingly* close to the statements in the CUI RFC.
> 
> It also requires uniqueness among the three-tuple (IdP namespace,
> RP namespace, value).
> 
> The eduPerson specs then build on top of that and introduce the no 
> reassignment requirement in their own spec.
> 
> So, what is wrong with taking the CUI as per RFC, extracting the
> value, adding the two-tuple of IdP and RP to it, plus requiring sth
> like "In addition to the requirements as per RFC, CUI values which
> are used in a Moonshot/ABFAB context MUST NOT be re-used."
> 
> This should clear most of the friction; and is really very similar
> to what eduPersonTargetedID does.
> 
> And as a further question, when your wishlist above states "what 
> precautions are taken to avoid re-use" - I must ask back: what are
> those precautions in eduPersonTargetedID, except for a "MUST NOT"
> in the spec? You can mandate the same for CUI-in-ABFAB with the
> same words :-)
> 
> Greetings,
> 
> Stefan Winter
> 
> [1] 
> http://software.internet2.edu/eduperson/internet2-mace-dir-eduperson-201310.html#eduPersonTargetedID
>