Hi Mert,
In that case as a starter...
We tackled extensions like this in STORK1 and STORK 2.0 and went for a slightly different definition of the Requested Attribute Type.
<complexType name="RequestedAttributeType">
<sequence>
<element ref="stork:AttributeValue" type="anyType" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<attribute name="Name" type="string" use="required"/>
<attribute name="NameFormat" type="anyURI" use="required"/>
<attribute name="FriendlyName" type="string" use="optional"/>
<anyAttribute namespace="##other" processContents="lax"/>
<attribute name="isRequired" type="boolean" use="optional"/>
</complexType>
To quote from the STORK specifications:
"The <stork:AttributeValue> element allows the requestor to specify that the attribute requested must have one of the specified values i.e. only return this attribute if the value of this attribute value (for the subject) is one of the requested values.
This is used to request derived attributes e.g. IsAgeOver. For example if the requestor wants to know if the subject is over 16 years old, then they can request the IsAgeOver attribute with the requested <stork:AttributeValue> of 16. If the subject was 18 the attribute would be returned in the SAML response assertion with a value of 16. If the subject was 15 then the resultant attribute in
the assertion would have no value.
Note this does not cater for complex conditions such as Is Subject aged between 15 and 18. Nevertheless, if the attribute isAgeOver is requested twice, e.g. one isAgeOver(15) and the other one isAgeOver(18), the reply gives information on whether or not the subject is in this range of ages."
One problem with things like this is they may be ignored (as your document says) by the IDP.
As an aside, in the UK we are actually looking at alternatives to the SAML attribute flow to keep identity and attribute enrichment separate but that is more of a policy decision on our part rather than anything else. This is due to a UK concern that there is a distinction between attributes related to the identity of a 'person' (natural or legal) and attributes related to the entitlement of that person to access a service or complete a transaction.
Happy to share learning from this and other SAML implementations if you think it would be useful.
I’m part of STORK 2.0, eIDAS and eSENS all of which have an interest in this area and share a common ancestor in STORK1 if that helps as well.
Thanks,
Adam