Purpose field for claims requests and revving of policy_url
Currently, we are relying on policy_url for the purpose statement for the claims request.
We have come some distance since we have defined it and the trend is to making it possible to state per claim purposes when needed. (see for example ISO/IEC 29184).
It might be a good time to consider something like:
{
"email":
{
"essential": true,
"purpose":"to send receipt",
"example":"alice@example.com"
}
}
Comments (4)
-
-
In our team, we are defining an extension in the same way. We are including “ns@purpose” (same name and a name space to avoid future collisions). It could be great to have that in the core spec. We also added a purpose field at the same level as “id_token” to explain the purpose of the full request, and another for the request of “proof” (another proprietary extension)
I do not see how the use of the “example” member could help in the OP/user interaction. At the end, he/she is going to provide data that it is already available in the OP
We are also thinking to include the language as part of the request to provide the OP a way to setup the lang in the consent.
-
It’s not clear whether this is intended to be machine-readable, and if so, what actions are anticipated as a result of its inclusion, or human-readable, in which case the RP would be providing UI elements to the OP. This is a questionable practice, as it results in mixed content. It would also result in localization challenges.
-
reporter - changed status to open
- Log in to comment
That’s a good idea In my experience, it ist often sufficient to have a request parameter informing the user of the purpose of the ongoing transaction.
see https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html#rfc.section.8