I've tried checking the lib and open issues/PRs, and I hope it's not noise, really sorry otherwise.
Is your feature request related to a problem? Please describe.
RFC 7591 client metadata include logo_uri, client_uri, tos_uri, policy_uri and contacts. Those are meant to be used to improve the quality of the signal the user gives when consenting. We currently ignore those.
DOT currently drops all of themboth in DCR and CIMD. There is no model field for any of them, so authorize.html can only ever show {{ application.name }} and the scope list.
Describe the solution you'd like
Attaching those to the Application, either through individual fields or a single JSON field (but individual fields would probably be better though contacts is a list).
Also, use those when present on authorize.html.
Describe alternatives you've considered
I maintain an ApplicationMetadata model (one-to-one to Application) for exactly this. It works, but every deployment with a real consent screen ends up writing it, and it can only be populated by subclassing the registration view to re-read the request body — the values are gone by the time the Application exists.
Additional context
If you think it's friendly work for a first contrib on the repo, then happy to give a try.
I've tried checking the lib and open issues/PRs, and I hope it's not noise, really sorry otherwise.
Is your feature request related to a problem? Please describe.
RFC 7591 client metadata include
logo_uri,client_uri,tos_uri,policy_uriandcontacts. Those are meant to be used to improve the quality of the signal the user gives when consenting. We currently ignore those.DOT currently drops all of themboth in DCR and CIMD. There is no model field for any of them, so
authorize.htmlcan only ever show{{ application.name }}and the scope list.Describe the solution you'd like
Attaching those to the Application, either through individual fields or a single JSON field (but individual fields would probably be better though
contactsis a list).Also, use those when present on
authorize.html.Describe alternatives you've considered
I maintain an
ApplicationMetadatamodel (one-to-one toApplication) for exactly this. It works, but every deployment with a real consent screen ends up writing it, and it can only be populated by subclassing the registration view to re-read the request body — the values are gone by the time theApplicationexists.Additional context
If you think it's friendly work for a first contrib on the repo, then happy to give a try.