Purpose field for claims requests and revving of policy_url

[Nat Sakimura]

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":"[e-mail]"
    }
}

[Torsten Lodderstedt]

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

[Victor Herraiz]

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.

[Michael Jones]

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.