[OpenID-Specs-eKYC-IDA] Move transaction specific purpose out of the main specification

[Axel.Nennker at telekom.de]

Hi,

in Camara<https://github.com/camaraproject/IdentityAndConsentManagement/> there is agreement that we need something like the purpose parameter that was removed from ekyc-ida with this issue.
https://bitbucket.org/openid/ekyc-ida/issues/1386/move-transaction-specific-purpose-out-of

We referenced the section from the ekyc-ida spec on the purpose parameter and wanted to use it.
https://github.com/AxelNennker/IdentityAndConsentManagement/blob/camara_oidc_profile/documentation/CAMARA-Security-Interoperability.md#purpose

Purpose

A transaction specific request parameter purpose as specified in openid-connect-4-identity-assurance-1_0-13<https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html#name-transaction-specific-purpos> MUST be used to allow a SP to state the purpose for the transfer of End-User data it is asking for. The purpose string MUST use below format for interoperability

dpv:<dpvValue>

<dpvValue> is coming from W3C DPV purpose definition<https://w3c.github.io/dpv/dpv/#vocab-purpose>
Then, later,  we discovered that ekyc-ida removed that parameter definition from the ekyc-ida protocol, bummer.

We found that @dima at postnikov.net<mailto:dima at postnikov.net> started writing a new Internet Draft for "purpose" in Oauth2.
https://cdn.connectid.com.au/specifications/oauth2-purpose-01.html#name-transaction-specific-purpos

Deutsche Telekom would support that draft. Other Camara member as well, probably.
We, DT, are willing to contribute to the new draft.

In Camara we envisioned that the value of the purpose parameter is ONE from the W3C DPV purpose definition.
We think that the value should not be a string provided by the client but from a fixed list an that the AZ then shows the end user a text that matches the user's and the AZ/RP's legislation/jurisdiction for that purpose.

An end user might give their consent to a location-service for the purpose of account takeover protection but not for some other purpose.
A mobile banking app might ask for consent for a location-service, that helps the user find the nearest ATM, but the user does give their consent for this convenience function.
A mobile banking app might ask for consent for a location-service, that validates that the user's mobile phone is in the vincinity of the ATM the user is withdrawing money from – and the end user is willing to get that protection.
Or the client might have a legitimate-interest<https://w3c.github.io/dpv/dpv/#LegitimateInterest> in using some API like location-service or sim-swap.

The removed ekyc-ida purpose parameter sounds like the CIBA binding_message parameter.
https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html#auth_request

Camara also discussed tweaking purpose into scopes, but that did not turn out well. Mainly, I think, because technical scopes have very little relationship with legislation/jurisdiction.

Could you please provide some context on why ekyc-ida removed the purpose parameter?
And, is there initial feedback from IETF Oauth2 WG on the new draft?

Kind regards
Axel



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ekyc-ida/attachments/20240422/a9d61598/attachment-0001.html>