[OpenID-Specs-eKYC-IDA] [External Sender] Re: Move transaction specific purpose out of the main specification
Axel.Nennker at telekom.de
Axel.Nennker at telekom.de
Thu Apr 25 13:32:51 UTC 2024
Hi George,
Thanks for the proposal.
Sure, RAR could be used and somebody actually proposed that during yesterday's Identitymanagement and Consent meeting.
https://github.com/camaraproject/IdentityAndConsentManagement/
RAR is quite new (May 2023) and telcos and aggregators are not really there when it comes to implementing more than bare OIDC or Oauth2.
Most have not even heard of RAR, I think.
RAR is quite generic and Camara would need to define all the details.
When using moving "purpose" to RAR we are hiding the problem one level lower, right?
## Here is a simple Camara API: https://github.com/camaraproject/SimSwap/blob/main/code/API_definitions/sim_swap.yaml
How about following request object? "action" is always "read" in this API, so no need to specify that. "Permissions" IDK. Scope in the yaml is similar to path, so no need for that.
Request an access token for one socpe/path/location:
[
{
"type": https://schemes.camaraproject.org/simswap,
"purpose": "dpv:FraudPreventionAndDetection#check-sim-swap",
"locations": [
https://server.example.net/sim-swap/v0/check
]
}
]
Request an access token for two:
[
{
"type": https://schemes.camaraproject.org/simswap,
"purpose": "dpv:FraudPreventionAndDetection#check-sim-swap",
"locations": [
https://server.example.net/sim-swap/v0/check
]
},
{
"type": https://schemes.camaraproject.org/simswap,
"purpose": "dpv:FraudPreventionAndDetection#retrieve-sim-swap-date",
"locations": [
https://server.example.net/sim-swap/v0/retrieve-date
]
}
]
Request an access token for two but different purpose:
[
{
"type": https://schemes.camaraproject.org/simswap,
"purpose": "dpv:LegitimateInterest#check-sim-swap",
"locations": [
https://server.example.net/sim-swap/v0/check
]
},
{
"type": https://schemes.camaraproject.org/simswap,
"purpose": "dpv:FraudPreventionAndDetection#retrieve-sim-swap-date",
"locations": [
https://server.example.net/sim-swap/v0/retrieve-date
]
}
]
In general, how to specify an request for any Camara API from its openapi.yaml:
"type" is "https://schemes.camaraproject.org/<path-prefix> e.g. "sim-swap/v0" or without the "version"
"purpose" is something defined something TBD
"locations" is the server/api-root + path
This might work, right?
From: George Fletcher <george.fletcher at capitalone.com>
Date: Wednesday, 24. April 2024 at 20:28
To: OpenID eKYC Identity Assurance Working Group <openid-specs-ekyc-ida at lists.openid.net>
Cc: blhjelm at gmail.com <blhjelm at gmail.com>, dima at postnikov.net <dima at postnikov.net>, torsten at lodderstedt.net <torsten at lodderstedt.net>, Nennker, Axel <Axel.Nennker at telekom.de>, Padgaonkar, Shilpa <Shilpa.Padgaonkar at telekom.de>
Subject: Re: [External Sender] Re: [OpenID-Specs-eKYC-IDA] Move transaction specific purpose out of the main specification
I think this could be as simple as defining the RAR request object as...
[
{
"type": "transaction_purpose",
"dpv": "<dpvValue>"
}
]
Thanks,
George
On Wed, Apr 24, 2024 at 2:25 PM George Fletcher <george.fletcher at capitalone.com<mailto:george.fletcher at capitalone.com>> wrote:
Is there a reason that RFC 9396<https://datatracker.ietf.org/doc/html/rfc9396> can not be used for this purpose (pun intended)? This is exactly why RAR was created to allow for this additional detail to be provided. There is provision to return additional "RAR" data in the response. I'm sure this was already discussed so if you can point me to that thread I would really appreciate it.
Thanks,
George
On Wed, Apr 24, 2024 at 2:20 PM 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:
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<mailto:blhjelm at gmail.com>>
Date: Wednesday, 24. April 2024 at 18:20
To: Nennker, Axel <Axel.Nennker at telekom.de<mailto:Axel.Nennker at telekom.de>>, dima at postnikov.net<mailto:dima at postnikov.net> <dima at postnikov.net<mailto:dima at postnikov.net>>
Cc: Padgaonkar, Shilpa <Shilpa.Padgaonkar at telekom.de<mailto:Shilpa.Padgaonkar at telekom.de>>, OpenID eKYC Identity Assurance Working Group <openid-specs-ekyc-ida at lists.openid.net<mailto:openid-specs-ekyc-ida at lists.openid.net>>, Bjorn Hjelm <bjorn.hjelm at oidf.org<mailto: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://urldefense.com/v3/__https:/github.com/camaraproject/IdentityAndConsentManagement/__;!!FrPt2g6CO4Wadw!IwQ7eGC6nAUfNRqZ3Vs7XTYq-vkHNtj5Q0IHE7chNKN0yPQQZHLFlDM4Bvn1SfM1bXHRj-jDnJBuUbn1b45lnaOidliy6orgXkjAsZDU$> 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<https://urldefense.com/v3/__https:/bitbucket.org/openid/ekyc-ida/issues/1386/move-transaction-specific-purpose-out-of__;!!FrPt2g6CO4Wadw!IwQ7eGC6nAUfNRqZ3Vs7XTYq-vkHNtj5Q0IHE7chNKN0yPQQZHLFlDM4Bvn1SfM1bXHRj-jDnJBuUbn1b45lnaOidliy6orgXiaLHS0T$>
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<https://urldefense.com/v3/__https:/github.com/AxelNennker/IdentityAndConsentManagement/blob/camara_oidc_profile/documentation/CAMARA-Security-Interoperability.md*purpose__;Iw!!FrPt2g6CO4Wadw!IwQ7eGC6nAUfNRqZ3Vs7XTYq-vkHNtj5Q0IHE7chNKN0yPQQZHLFlDM4Bvn1SfM1bXHRj-jDnJBuUbn1b45lnaOidliy6orgXoIajKpK$>
Purpose
A transaction specific request parameter purpose as specified in openid-connect-4-identity-assurance-1_0-13<https://urldefense.com/v3/__https:/openid.net/specs/openid-connect-4-identity-assurance-1_0.html*name-transaction-specific-purpos__;Iw!!FrPt2g6CO4Wadw!IwQ7eGC6nAUfNRqZ3Vs7XTYq-vkHNtj5Q0IHE7chNKN0yPQQZHLFlDM4Bvn1SfM1bXHRj-jDnJBuUbn1b45lnaOidliy6orgXtMqmcCP$> 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://urldefense.com/v3/__https:/w3c.github.io/dpv/dpv/*vocab-purpose__;Iw!!FrPt2g6CO4Wadw!IwQ7eGC6nAUfNRqZ3Vs7XTYq-vkHNtj5Q0IHE7chNKN0yPQQZHLFlDM4Bvn1SfM1bXHRj-jDnJBuUbn1b45lnaOidliy6orgXj6-RYjK$>
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<https://urldefense.com/v3/__https:/cdn.connectid.com.au/specifications/oauth2-purpose-01.html*name-transaction-specific-purpos__;Iw!!FrPt2g6CO4Wadw!IwQ7eGC6nAUfNRqZ3Vs7XTYq-vkHNtj5Q0IHE7chNKN0yPQQZHLFlDM4Bvn1SfM1bXHRj-jDnJBuUbn1b45lnaOidliy6orgXrSelMk-$>
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://urldefense.com/v3/__https:/w3c.github.io/dpv/dpv/*LegitimateInterest__;Iw!!FrPt2g6CO4Wadw!IwQ7eGC6nAUfNRqZ3Vs7XTYq-vkHNtj5Q0IHE7chNKN0yPQQZHLFlDM4Bvn1SfM1bXHRj-jDnJBuUbn1b45lnaOidliy6orgXv-OIqBq$> 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<https://urldefense.com/v3/__https:/openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html*auth_request__;Iw!!FrPt2g6CO4Wadw!IwQ7eGC6nAUfNRqZ3Vs7XTYq-vkHNtj5Q0IHE7chNKN0yPQQZHLFlDM4Bvn1SfM1bXHRj-jDnJBuUbn1b45lnaOidliy6orgXpU9xw3r$>
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<https://urldefense.com/v3/__https:/lists.openid.net/mailman/listinfo/openid-specs-ekyc-ida__;!!FrPt2g6CO4Wadw!IwQ7eGC6nAUfNRqZ3Vs7XTYq-vkHNtj5Q0IHE7chNKN0yPQQZHLFlDM4Bvn1SfM1bXHRj-jDnJBuUbn1b45lnaOidliy6orgXuvTgGcl$>
--
Kind Regards,
Bjorn
--
Openid-specs-ekyc-ida mailing list
Openid-specs-ekyc-ida at lists.openid.net<mailto:Openid-specs-ekyc-ida at lists.openid.net>
https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ekyc-ida__;!!FrPt2g6CO4Wadw!IwQ7eGC6nAUfNRqZ3Vs7XTYq-vkHNtj5Q0IHE7chNKN0yPQQZHLFlDM4Bvn1SfM1bXHRj-jDnJBuUbn1b45lnaOidliy6orgXuvTgGcl$<https://urldefense.com/v3/__https:/lists.openid.net/mailman/listinfo/openid-specs-ekyc-ida__;!!FrPt2g6CO4Wadw!IwQ7eGC6nAUfNRqZ3Vs7XTYq-vkHNtj5Q0IHE7chNKN0yPQQZHLFlDM4Bvn1SfM1bXHRj-jDnJBuUbn1b45lnaOidliy6orgXuvTgGcl$>
________________________________
The information contained in this e-mail may be confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ekyc-ida/attachments/20240425/fac0f3fa/attachment-0001.html>
More information about the Openid-specs-ekyc-ida
mailing list