peppelinux
commented
7 months ago converter.from_internal belongs to the SATOSA internal API, I would suggest to open an issue here, referencing this one
the reason why it returns as a list is because you can have a complex mapping where more than a single value would be mappend to a single claim name, that can be also multivalued (array)
I am mapping an attribute that is already used in other OIDC systems in Brazil. The attribute is the "cpf" Individual Taxpayer Registry.
Existing RPs expect to receive this attribute as follows: "cpf": "00000000000",
And OIDCOP is delivering it like this: "cpf": [ "00000000000" ],
After going through the backend (SAML) and "self.converter.from_internal" being delivered, the Frontend plugin (OIDCOP) evaluates the attributes in the handle_authn_response function in the "combined_claims" step where it checks the attributes registered in "core/claims.py" .
Registered attributes are combined into just one value. In other words, it would solve my problem, so I could use SATOSA with OIDCOP to integrate with these RPs.
However, I wanted to ask if there is any other solution to this scenario. Personal attributes, which uniquely identify an entity, delivered as a string, but cannot be a list. Is there any other way to deliver the attribute without having to edit the OIDCOP library?
Note: The Individual Taxpayer Registry (CPF) is the taxpayer registry maintained by the Brazilian Federal Revenue Service in which any natural person, regardless of age or nationality, including deceased individuals, can register once. Each enrollee is uniquely identified by a CPF registration number made up of 11 decimal digits, personal and non-transferable throughout their life, never changing except by court decision.