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

Wed Apr 24 18:19:58 UTC 2024

Bjorn,

In today's ICM meeting the purpose-parameter proposal died.
We are back to encoding-purpose-in-scope.

I proposed some new text, that I think is better than the previous 0.1 text on encoding-purpose-in-scope.

My understanding of the IETF process is that new drafts are send to the mailing list asking the WG to add them as a work item.
Yes, I also remember that messages-for-transactions or purpose-for-transactions was tried before.
I remember that the last time this was discussed @Torsten Lodderstedt<mailto:torsten at lodderstedt.net> said that "transactions" are not well enough understood.
But that was years ago and maybe now we find a the next small step forward that helps.

Let's see what Dima says

Kind regards
Axel

From: Bjorn Hjelm <blhjelm at gmail.com>
Date: Wednesday, 24. April 2024 at 18:20
To: Nennker, Axel <Axel.Nennker at telekom.de>, dima at postnikov.net <dima at postnikov.net>
Cc: Padgaonkar, Shilpa <Shilpa.Padgaonkar at telekom.de>, OpenID eKYC Identity Assurance Working Group <openid-specs-ekyc-ida at lists.openid.net>, Bjorn Hjelm <bjorn.hjelm at oidf.org>
Subject: Re: [OpenID-Specs-eKYC-IDA] Move transaction specific purpose out of the main specification
Axel,
As noted, Dima has created a draft intended for IETF on purpose based on the discussions in the eKYC-IDA working group. Until introduced, we don't know the feedback from the IETF community on this proposal but it's my understanding that this isn't the first time this topic has been discussed within IETF. There's also a similar discussion about purpose taking place in the DPC working group worth noting that may impact the approach of a technical specification.

As Dima is traveling, I believe he'll add some additional details and insight to this e-mail thread.

Finally, I would highly encourage CAMARA to take issue to the OpenID Foundation when it relates to parameter usage (as mentioned about tweaking purpose into scopes) to ensure that the OpenID Connect specifications and profiles are utilized in accordance to its purpose and that the Foundation has offered up the wealth of knowledge that exists within the Foundation to assist CAMARA.

Kind Regards,
Bjorn

On Mon, Apr 22, 2024 at 3:35 AM Axel.Nennker--- via Openid-specs-ekyc-ida <openid-specs-ekyc-ida at lists.openid.net<mailto:openid-specs-ekyc-ida at lists.openid.net>> wrote:
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

--
Openid-specs-ekyc-ida mailing list
Openid-specs-ekyc-ida at lists.openid.net<mailto:Openid-specs-ekyc-ida at lists.openid.net>
https://lists.openid.net/mailman/listinfo/openid-specs-ekyc-ida

--
Kind Regards,
Bjorn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ekyc-ida/attachments/20240424/e59b1e3d/attachment-0001.html>