Non-Standard Attribute Release

[Peter Schober]

* Dan Malone <dmalone at calpoly.edu> [2015-06-09 18:41]:
> We have the value needed in a different attribute and I want to the overloading of this attribute to be specific to this vendor.
> Will this work and/or is there a better way?
[...]
>         <resolver:AttributeDefinition xsi:type="ad:Simple" id="parchmentComStudentID" sourceAttributeID="calstateEduPersonEmplid">
>             <resolver:Dependency ref="myLDAP" />
>             <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:oid:0.9.2342.19200300.100.1.44" />
>             <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:0.9.2342.19200300.100.1.44" friendlyName="uniqueIdentifier" />
>         </resolver:AttributeDefinition>

Yes, you create another attribute definition with the desired encoder
and put the existing attribute that has the same (desired) value into
the sourceAttributeID. Maybe put calstateEduPersonEmplid in as
Dependency too.

Now whether the vendor actually wants you to send the urn:oid: name of
that attribute is somewhat questionable (as far as vendors go), but I
can't speak to that. If it wants the attribute to be the literal
string "uniqueIdentifier" you'd have to change thenameFormat too.

If that vendor is somewhat popular in US HE it may make more sense to
gather a bunch of customers and approach the vendor with "strengh in
numbers". Not sure whether your federation operator (InCommon) also
does federation customer relationships, they too might be able to
convince the vendor into accepting a less under-defined attribute on
behalf of their member community. Try one of the InCommon provided
mailing lists any of that.
-peter