search

camaraproject / IdentityAndConsentManagement

Repository to describe, develop, document and test the Identity And Consent Management for CAMARA APIs
Apache License 2.0
18 stars 30 forks source link

Camara OIDC profile #121

Closed AxelNennker closed 1 month ago

AxelNennker commented 4 months ago

What type of PR is this?

Add one of the following kinds:

What this PR does / why we need it:

By restricting options the OIDF and IETF standards offer this document improves CAMARA security and interoperability. The CAMARA Security and Interoperability document follows the path FAPI 2.0 Security took, leading to a concise description which helps implementers focusing on those parts of the standards that are required or recommended.

Which issue(s) this PR fixes:

Fixes #78 Fixes #82 Fixes #87 Fixes #90 Fixes #100 Fixes #104
Fixes #127 Fixes #132 Fixes #133 Fixes #136 Fixes #137

eric-murray commented 4 months ago

What is the intention for parameters and behaviour that remain optional (whether recommended or only optional)? Is it the intention that an API provider can choose which optional features to support and which not?

AxelNennker commented 4 months ago

What is the intention for parameters and behaviour that remain optional (whether recommended or only optional)? Is it the intention that an API provider can choose which optional features to support and which not?

If Camara has already specified some behavior regarding optional parameters then the specified behavior should be here because interoperability. If there is no current specification, and somebody thinks there should be, then please write a PR after this PR is merged. Ok, @eric-murray ?

AxelNennker commented 4 months ago

@jpengar @Elisabeth-Ericsson @eric-murray @palmerabollo I think all comments are resolved. Thanks for your comments and reviews.

eric-murray commented 4 months ago

@AxelNennker

If Camara has already specified some behavior regarding optional parameters then the specified behavior should be here because interoperability. If there is no current specification, and somebody thinks there should be, then please write a PR after this PR is merged. Ok, @eric-murray ?

I'm not aware of any explicit agreement as to whether parameters that remain optional need to be supported by API providers. Both profile proposals make previously optional parameters such as login_hint mandatory, so there is no issue there.

I'm happy to merge one of the profile proposals so long as it is understood there is no agreement on whether or not optional parameters need to be supported by API providers. A related question is whether an API provider can mandate that an API consumer support a particular optional parameter. My general view there is that, if the option is recommended, then indeed an API provider can mandate that it is supported by their clients.

palmerabollo commented 4 months ago

@eric-murray

I'm happy to merge one of the profile proposals so long as it is understood there is no agreement on whether or not optional parameters need to be supported by API providers.

Agree.

A related question is whether an API provider can mandate that an API consumer support a particular optional parameter. My general view there is that, if the option is recommended, then indeed an API provider can mandate that it is supported by their clients.

I don't see how this would work without breaking interoperability. For example, the "state" parameter is recommended. If API provider A makes it mandatory and API provider B makes it optional, a developer cannot build an interoperable application (that works for both A & B). So either recommended parameters are optional or they are mandatory for all –and should be reflected as such in the profile.

AxelNennker commented 4 months ago

A related question is whether an API provider can mandate that an API consumer support a particular optional parameter. My general view there is that, if the option is recommended, then indeed an API provider can mandate that it is supported by their clients.

I don't see how this would work without breaking interoperability. For example, the "state" parameter is recommended. If API provider A makes it mandatory and API provider B makes it optional, a developer cannot build an interoperable application (that works for both A & B). So either recommended parameters are optional or they are mandatory for all –and should be reflected as such in the profile.

AZ/OP are REQUIRED to support state because state is REQUIRED in the success and in the error case if state was in the request. state is RECOMMENDED for clients. There is no clarification needed regarding state.

Are there examples of other request parameters that need to be clarified for interoperability reasons? State is no such example, I think.

AZ/OP should be OIDF certified. I think an AZ/OP does not pass certification of the state value is not in the success response or the error response or altered.

palmerabollo commented 4 months ago

AZ/OP are REQUIRED to support state because state is REQUIRED in the success and in the error case if state was in the request. state is RECOMMENDED for clients.

You are right. It was just one example. What I mean is that an API provider cannot make a recommended parameter (or capability, e.g., PKCE) mandatory for clients because that would break app interoperability.

murthygorty commented 4 months ago

AZ/OP are REQUIRED to support state because state is REQUIRED in the success and in the error case if state was in the request. state is RECOMMENDED for clients.

You are right. It was just one example. What I mean is that an API provider cannot make a recommended parameter (or capability, e.g., PKCE) mandatory for clients because that would break app interoperability.

I humbly disagree.

ONE solution: define standards both in IDM and 'Runtime restrictions' that allow Developers (and SDKs) to manage the different operator needs.

This way, the Developers have a programmatic way of building a single solution.

cc: @gmuratk @shilpa-padgaonkar @AxelNennker @mengan

palmerabollo commented 4 months ago

@murthygorty could you please elaborate on this?

define standards both in IDM and 'Runtime restrictions' that allow Developers (and SDKs) to manage the different operator needs.

Interoperability is a must. I don't understand if you propose that operators are not interoperable and have an SDK containing logic such as if (Telefonica) do this else if (T-Mobile) do that else ... or force devs to deal with operators' particularities. App devs shouldn't even know what telco the end user belongs to. I think that goes against the spirit of CAMARA.

This is why the profile needs to cover everything needed for telcos be interoperable. If something is optional or recommended, an operator can not fail if the client decides to optionally not send it. Otherwise we must make it required.

murthygorty commented 4 months ago

@murthygorty could you please elaborate on this?

define standards both in IDM and 'Runtime restrictions' that allow Developers (and SDKs) to manage the different operator needs.

Interoperability is a must. I don't understand if you propose that operators are not interoperable and have an SDK containing logic such as if (Telefonica) do this else if (T-Mobile) do that else ... or force devs to deal with operators' particularities. App devs shouldn't even know what telco the end user belongs to. I think that goes against the spirit of CAMARA.

This is why the profile needs to cover everything needed for telcos be interoperable. If something is optional or recommended, an operator can not fail if the client decides to optionally not send it. Otherwise we must make it required.

sorry I wasn't clear, @palmerabollo. Definitely, the basis of CAMARA is what you said. My point is just that there are several other aspects that need to be in place before interoperability is in place. Elaboration:

murthygorty commented 4 months ago

@murthygorty could you please elaborate on this?

define standards both in IDM and 'Runtime restrictions' that allow Developers (and SDKs) to manage the different operator needs.

Interoperability is a must. I don't understand if you propose that operators are not interoperable and have an SDK containing logic such as if (Telefonica) do this else if (T-Mobile) do that else ... or force devs to deal with operators' particularities. App devs shouldn't even know what telco the end user belongs to. I think that goes against the spirit of CAMARA. This is why the profile needs to cover everything needed for telcos be interoperable. If something is optional or recommended, an operator can not fail if the client decides to optionally not send it. Otherwise we must make it required.

sorry I wasn't clear, @palmerabollo. Definitely, the basis of CAMARA is what you said. My point is just that there are several other aspects that need to be in place before interoperability is in place. Elaboration:

  • runtime restrictions is a new capability that has just gone in front of TSC I believe.
  • another example: each family must define what APIs are must (and perhaps categorize APIs as higher level to api-endpoints etc.)
  • camara release mgmt and ogw will help clear some of these hurdles.

Also @palmerabollo, hope you understood what I was saying on the security profile that I cant visualize a one-size-fits-all for the reasons I mentioned above.

AxelNennker commented 4 months ago

AZ/OP are REQUIRED to support state because state is REQUIRED in the success and in the error case if state was in the request. state is RECOMMENDED for clients.

You are right. It was just one example. What I mean is that an API provider cannot make a recommended parameter (or capability, e.g., PKCE) mandatory for clients because that would break app interoperability.

I humbly disagree.

@murthygorty Do you disagree with what I stated about state? Or do you disagree with the PKCE part?

I think regarding state we do not need text in this document.

The proposed security and interoperability document had text on PKCE but participants are not ready for this version of the document to include anything about PKCE. So, I removed that section. Although, I am sure that the discussion about PKCE is coming in the future because OAuth2 Security demands it for authorization code flow with public clients (mobile apps, browser apps).

Public clients MUST use PKCE

@murthygorty anything specific you want to have added, amended or removed from this document? Please propose text.

AxelNennker commented 3 months ago

@jpengar thanks for the updated TOC. Did you use a tool to create that? I decided to do the TOC update only from time to time. It was ugly anyway. And do the final TOC just before the merge. Much better now. Thanks again.

garciasolero commented 3 months ago

@jpengar thanks for the updated TOC. Did you use a tool to create that?

If you work with a JetBrains IDE, it generates and updates it for you using this shortcut.

jpengar commented 3 months ago

@jpengar thanks for the updated TOC. Did you use a tool to create that? I decided to do the TOC update only from time to time. It was ugly anyway. And do the final TOC just before the merge. Much better now. Thanks again.

@AxelNennker You're welcome. I'm using VS Code Editor and the Markdown All in One extension which I found very useful. Among other things, it generates a table of contents and automatically updates it every time you save the document.

AxelNennker commented 3 months ago

@jpengar @garciasolero are you OK with the section on refresh token and offline access in this document? I think it basically defines what https://github.com/camaraproject/IdentityAndConsentManagement/pull/123 says.

AxelNennker commented 3 months ago

@jpengar regarding purpose, offline, PPID...

Are you OK with the id token sub claim text, which recommends PPID but does not require anything? Are you OK with the offline text, which is now in its own section for both flows?

AxelNennker commented 3 months ago

Check where consent_required is defined and reference it in the profile.

garciasolero commented 3 months ago

In order to summarize the outstanding issues, from Telefónica side, to accept this profile and merge this PR we would need the following comments to be taken into account:

AxelNennker commented 3 months ago 
* How to handle the absence of the `openid` scope in the authorize request: [PR comment](https://github.com/camaraproject/IdentityAndConsentManagement/pull/121/files#r1506195202)

I commented on the referenced comment and hope we can agree to follow the OIDC standard that "openid" is a required scope.

garciasolero commented 3 months ago

I commented on the referenced comment and hope we can agree to follow the OIDC standard that "openid" is a required scope.

We agree that the openid scope is listed as required in the standard, but it does not specify a behavior in case it is not sent.

scope REQUIRED. OpenID Connect requests MUST contain the openid scope value. If the openid scope value is not present, the behavior is entirely unspecified.[...]

In this profile, a behavior is being established (returninginvalid_request) that I think it could impact on implementations where OAuth2 and OIDC solutions coexist.

AxelNennker commented 2 months ago

New text on "missing openid value in scope parameter" which mentions the role of id token in OIDC https://github.com/AxelNennker/IdentityAndConsentManagement/blob/camara_oidc_profile/documentation/CAMARA-Security-Interoperability.md

@garciasolero trying to incorparate your above comments. Please review

bhjelm commented 2 months ago 
* How to handle the absence of the `openid` scope in the authorize request: [PR comment](https://github.com/camaraproject/IdentityAndConsentManagement/pull/121/files#r1506195202)

I commented on the referenced comment and hope we can agree to follow the OIDC standard that "openid" is a required scope.

bhjelm commented 2 months ago

Given that this text reference OAuth 2.0 and OpenID Connect, I would suggest that a section be added in terms of terminology (such as "Requirements Notation and Conventions" in OpenID Connect Core) that reference RFC 2119 for the terminology used aligning with both OAuth 2.0 and OpenID Connect.

AxelNennker commented 2 months ago

Given that this text reference OAuth 2.0 and OpenID Connect, I would suggest that a section be added in terms of terminology (such as "Requirements Notation and Conventions" in OpenID Connect Core) that reference RFC 2119 for the terminology used aligning with both OAuth 2.0 and OpenID Connect.

@bhjelm Such a text is already there https://github.com/AxelNennker/IdentityAndConsentManagement/blob/camara_oidc_profile/documentation/CAMARA-Security-Interoperability.md#conventions

jpengar commented 2 months ago

@AxelNennker @Elisabeth-Ericsson @shilpa-padgaonkar @palmerabollo and all, as agreed in 10/04 meeting please find below a proposal for a disclaimer text to consider existing implementations using the purpose solution specified in release v0.1.0 CAMARA-API-access-and-user-consent.md#applying-purpose-concept-in-the-authorization-request.

--

Disclaimer: This document introduces a new method for handling the "purpose" of access sessions in OpenID Connect for CAMARA. Please note:

By adhering to these guidelines, stakeholders can smoothly transition to the new CAMARA profile while ensuring continued compatibility and standards compliance.

AxelNennker commented 2 months ago

@AxelNennker @Elisabeth-Ericsson @shilpa-padgaonkar @palmerabollo and all, as agreed in 10/04 meeting please find below a proposal for a disclaimer text to consider existing implementations using the purpose solution specified in release v0.1.0 CAMARA-API-access-and-user-consent.md#applying-purpose-concept-in-the-authorization-request.

--

Disclaimer: This document introduces a new method for handling the "purpose" of access sessions in OpenID Connect for CAMARA. Please note:

* **Breaking Change Alert:** this new specification requires updates to existing implementations and is not backward compatible with the original solution defined in the [v0.1.0 release](https://github.com/camaraproject/IdentityAndConsentManagement/blob/release-0.1.0/documentation/CAMARA-API-access-and-user-consent.md#applying-purpose-concept-in-the-authorization-request).

* **Adoption Requirement:** All parties must adopt this CAMARA profile upon release to maintain interoperability and security.

* **Transitional Period:** Existing implementations may continue to use the previous solution during a specified transition period. Early migration is encouraged.

* **End of Legacy Support:** Support for the previous "purpose" handling mechanism will be phased out after the transition period.

By adhering to these guidelines, stakeholders can smoothly transition to the new CAMARA profile while ensuring continued compatibility and standards compliance.

Added the disclaimer to the document https://github.com/AxelNennker/IdentityAndConsentManagement/blob/camara_oidc_profile/documentation/CAMARA-Security-Interoperability.md Please review

AxelNennker commented 2 months ago

Dear ICM members,

I would like to merge this PR this month.

We moved some issues out of this PR to organize the discussion. These issues are listed above in the "fixes" list.

clarify the "credentials" notion in CIBA workflow authentication @sebdewet

Redundancy with GSMA API General Federated Call Flows document @bigludo7

OIDC guidance (what needs to be adhered to?) https://github.com/ECORMAC

Claims to be used in oAuth Access tokens/ OIDC Identity tokens @Elisabeth-Ericsson

Alignment of Client Credential authentication / authorization using API Gateway Pattern @mhfoo

Add missing response errors in CIBA flow from GSMA doc @jpengar

Proposal to define a strict value for aud claim in the private_key_jwt @mhfoo

Clarify on the need of optional claims in CIBA Client Authentication request. @shilpa-padgaonkar

Clarification needed for login_hint, login_hint_token and id_token_hint @shilpa-padgaonkar

Clarify role and usage of id token @Elisabeth-Ericsson

The "fixes"-list means that the issue is going to be auto-closed when the PR is merged. If you think an issue is not resolved by the current version of this PR then please speak up and we decide whether to remove it from the fixes list and continue the discussion of that issue for the next version or whether the issue blocks merging the PR (hope not).

@garciasolero three weeks ago kindly created a list of open issues in TEF's PoV

How to handle the absence of the openid scope in the authorize request: [PR comment](https://github.com/camaraproject/IdentityAndConsentManagement/pull/121/files#r1506195202)
Valid values for aud claim in client assertions: https://github.com/camaraproject/IdentityAndConsentManagement/issues/127#issuecomment-1970626141
When requesting a refresh token and the consent is revoked by the user, consent_required is not defined as an allowable error in the token endpoint. We should reach an agreement on which error to return. [PR comment](https://github.com/camaraproject/IdentityAndConsentManagement/pull/121/files#r1549724281)
The Purpose section does not currently contain the agreed-upon content. Either we remove that section or it should include what was agreed upon for version [0.1.0](https://github.com/camaraproject/IdentityAndConsentManagement/blob/release-0.1.0/documentation/CAMARA-API-access-and-user-consent.md#applying-purpose-concept-in-the-authorization-request). The final solution cannot be achieved in the short term, and this is how we can unblock the pull request.

I think those issues are addressed. Maybe not to the fullest extend of the issue but I think we found a way forward.

AxelNennker commented 2 months ago

Regarding implementation of "purpose" parameter in IdPs: @shilpa-padgaonkar found this https://github.com/identityfirst/eKYC-Hub/blob/main/keycloak-eKYC-plugin/keycloak-eKYC-module/src/main/java/tech/identityfirst/authenticatorforms/VerifiedClaimsAuthenticatorForm.java#L82

eric-murray commented 2 months ago

Regarding implementation of "purpose" parameter in IdPs: @shilpa-padgaonkar found this https://github.com/identityfirst/eKYC-Hub/blob/main/keycloak-eKYC-plugin/keycloak-eKYC-module/src/main/java/tech/identityfirst/authenticatorforms/VerifiedClaimsAuthenticatorForm.java#L82

I can't find any documentation for this implementation.

hdamker commented 2 months ago

Regarding implementation of "purpose" parameter in IdPs: @shilpa-padgaonkar found this https://github.com/identityfirst/eKYC-Hub/blob/main/keycloak-eKYC-plugin/keycloak-eKYC-module/src/main/java/tech/identityfirst/authenticatorforms/VerifiedClaimsAuthenticatorForm.java#L82

I can't find any documentation for this implementation.

@eric-murray I understood that you are on same stage regarding a top-level purpose parameter, but not happy to define it with a reference to a draft spec which is in addition ambiguous. Would you mind to propose an alternative normative definition for our profile which would fit for you?

eric-murray commented 2 months ago

I understood that you are on same stage regarding a top-level purpose parameter, but not happy to define it with a reference to a draft spec which is in addition ambiguous. Would you mind to propose an alternative normative definition for our profile which would fit for you?

Alternative text proposed.

hdamker commented 2 months ago

Unfortunately I wasn't able to attend yesterday's ICM meeting but have read the minutes. I'm concerned about the outcome. The proposed solution to declare purpose is complex, not extensible and comes with undefined semantics and therefore will lead to different implementations (see my comment in #140).

I still support to start with Option 1 of #140, start with a simple purpose parameter, and then collaborate with OIDF and others to extend the purpose declaration later to more complex (business) use cases.

shilpa-padgaonkar commented 2 months ago

I still support option1 and then transition to RAR if we move towards more complex usecases (as we will have time to work on the structure together). A very simple RAR example could include in authorization_details

[
  {
    "type": "org.camaraproject.simswap",
    "purpose": "dpv:FraudPreventionAndDetection"
  }
]

Is the argument to not support option1 for now, only based on the fact that it is not a part of https://openid.bitbucket.io/ekyc/openid-connect-4-identity-assurance.html?

@AxelNennker Normally after the last change to PR, my approval should be reset. It seemed to stay as-is. Would you be able to reset it?

AxelNennker commented 2 months ago

Please review https://github.com/AxelNennker/IdentityAndConsentManagement/blob/icm_examples/documentation/CAMARA-ICM-examples.md

I hope that the examples show that multiple purpose values are possible and easy to implement for both the AZ and the RS (aggregator or not).

The difficulties we had with purpose are gone with the current text, I think. I admit that wild-card scopes are gone for now, but I claim that the wild-card claims caused some of the trouble we had with purpose. By postponing wild-card scopes to the next version we separate two topics that do not have any relationship: purpose and wild-cardscopes. By separating these two topics we are making progress, I think.

mhfoo commented 2 months ago

Please review https://github.com/AxelNennker/IdentityAndConsentManagement/blob/icm_examples/documentation/CAMARA-ICM-examples.md

@AxelNennker

I believe the RFC9101 request object examples in the above link should have the following claims, as per RFC7519:

bigludo7 commented 2 months ago

Please review https://github.com/AxelNennker/IdentityAndConsentManagement/blob/icm_examples/documentation/CAMARA-ICM-examples.md

Hello @mhfoo I've a problem for the examples. For my understanding legitimateInterest is not a dpv purpose but a dpv legalBase. As such it must not be in the scope field. Could you check/fix this if I'm right and use correct purpose as servicePersonalization for example? It is confusing as such.

mhfoo commented 2 months ago

Hello @mhfoo I've a problem for the examples. For my understanding legitimateInterest is not a dpv purpose but a dpv legalBase. As such it must not be in the scope field. Could you check/fix this if I'm right and use correct purpose as servicePersonalization for example? It is confusing as such.

@bigludo7

The above question is for @AxelNennker? I think you tag the wrong person.

bigludo7 commented 2 months ago

Hello @mhfoo I've a problem for the examples. For my understanding legitimateInterest is not a dpv purpose but a dpv legalBase. As such it must not be in the scope field. Could you check/fix this if I'm right and use correct purpose as servicePersonalization for example? It is confusing as such.

@bigludo7

The above question is for @AxelNennker? I think you tag the wrong person.

Sorry @mhfoo and you're right. Yes this is a point for @AxelNennker

Axel my point is the following: I've a problem for the examples. For my understanding legitimateInterest is not a dpv purpose but a dpv legalBase. As such it must not be in the scope field. Could you check/fix this if I'm right and use correct purpose as servicePersonalization for example? It is confusing as such.

jpengar commented 2 months ago

As suggested in last WG call (24/04), Telefónica supports going with option 1 (use a separate "purpose" request param and only one purpose per authorisation request - see #140 ) for now, given the existing requirements, and if more complex scenarios arise in the future, we can think about other solutions like RAR (OAuth 2.0 Rich Authorisation Requests - https://datatracker.ietf.org/doc/html/rfc9396) or other potential options that we may agree.

mhfoo commented 2 months ago

As suggested in last WG call (24/04), Telefónica supports going with option 1 (use a separate "purpose" request param and only one purpose per authorisation request - see #140 ) for now, given the existing requirements, and if more complex scenarios arise in the future, we can think about other solutions like RAR (OAuth 2.0 Rich Authorisation Requests - https://datatracker.ietf.org/doc/html/rfc9396) or other potential options that we may agree.

Singtel agrees to separate the "purpose" request parameter and allow only one purpose per authorisation request (to separate the access token purpose), for data access auditing.

AxelNennker commented 2 months ago

Hello @mhfoo I've a problem for the examples. For my understanding legitimateInterest is not a dpv purpose but a dpv legalBase. As such it must not be in the scope field. Could you check/fix this if I'm right and use correct purpose as servicePersonalization for example? It is confusing as such.

@bigludo7 The above question is for @AxelNennker? I think you tag the wrong person.

Sorry @mhfoo and you're right. Yes this is a point for @AxelNennker

Axel my point is the following: I've a problem for the examples. For my understanding legitimateInterest is not a dpv purpose but a dpv legalBase. As such it must not be in the scope field. Could you check/fix this if I'm right and use correct purpose as servicePersonalization for example? It is confusing as such.

My mistake. I just wanted to have too different purpose. I replaced all LegitimateInterest by something from the purpose section https://w3c.github.io/dpv/dpv/#vocab-purposes Changed document is here https://github.com/AxelNennker/IdentityAndConsentManagement/blob/icm_examples/documentation/CAMARA-ICM-examples.md

AxelNennker commented 2 months ago

In preparation for next Tuesday's meeting I wrote down some options I think we have regarding purpose. https://github.com/AxelNennker/IdentityAndConsentManagement/blob/camara_oidc_profile/documentation/CAMARA-Security-Interoperability.md#purpose

Purpose

In Camara purpose is used to convey to the user for which purpose an API is used. E.g.: Does the client request the user's location because it wants to show relevant tourist information or is the user's location informat protecting the user when they withdraw money from an ATM? Therefore purposeis only used in Camara when user consent is required (CIBA or OIDC authorization code flow) and a potential prompt parameter's value is NOT none.

Note

Pick one of the following options

Option 1: Purpose as a scope

Purpose is one of the scope parameter's values. There MUST be exactly one purpose.

The Authorization Server identifies the purpose using the prefix dpv:.

This scope MUST have the following format: dpv:<dpvValue> where <dpvValue> is coming from W3C DPV purpose definition

Option 2: Purpose encoded in scope

It is OPTIONAL to declare purpose in a scope, but then the scope MUST have this format: dpv:<dpvValue>#<technicalParameter>

There SHOULD not be two scopes that are the same technical scope for different purposes.

Option 3: Purpose as a Authentication Request Parameter

It is OPTIONAL to declare purpose as a request parameter in the authentication request. The purpose parameter is an extension of OIDC. If the purpose parameter is used then its value MUST be a single value coming from W3C DPV purpose definition. Multiple purpose parameters are not allowed.

Option 4: Use Rich Authorization Request to convey purpose

RFC 9396 OAuth 2.0 Rich Authorization Requests defines a OAuth2 parameter authorization_details that is used to carry fine-grained authorization data. The parameter authorization_details can be used in all places where OAuth2 allows the scope parameter. That means that the parameter authorization_details can be used in all places where OIDC and CIBA allow the scope parameter.

This document defines exactly one format to be used in Camara for the value of the authorization_details parameter that is used additionally to the scope parameter.

[
  {
    "type": "org.camaraproject.<Camara-API-Name>",
    "purpose": "dpv:<dpvValue>"
  }
]

<dpvValue> is coming from W3C DPV purpose definition

I think that for now we agree that there is exactly one purpose, although some of the options might allow multiple purposes but there was no clear business requirement in #140 and we decided to go for one purpose for now and continue the discussion on future requirements in the next release.

Features of the options (pros and cons)

Purpose as a scope

Purpose encoded in scope

Purpose as a Authentication Request Parameter

Use Rich Authorization Request to convey purpose

AxelNennker commented 2 months ago

Please express your and your companies preference for the different purpose options.

Option 1: Purpose as a scope

Option 2: Purpose encoded in scope

Option 3: Purpose as a Authentication Request Parameter

Option 4: Use Rich Authorization Request to convey purpose

bigludo7 commented 2 months ago

From Orange (and without @sebdewet who's lead this work) our strong preference is to have a standardized solution. As such we will not be able to accommodate option 3. In option 1 there is a mismatch between 2 distinct things: purpose and the data claimed.

We vote for option 2 with complete scope. As fallback we prefer option 4 .

jpengar commented 2 months ago

Telefónica supports Option 3 (Purpose as Authentication Request Parameter) for the next release, given the existing requirements (see #140). And if more complex scenarios arise in the future, we support Option 4 (Use Rich Authorisation Request to convey purpose) as the preferred option for future releases. But we tend to see the use of RAR as a bit premature for today's needs, it should be considered cautiously. Although we see it as a great option for the future to support scenarios like N-purposes if they are eventually needed. We could keep option 3 as a valid option if there is only one purpose, thus ensuring backwards compatibility.

AxelNennker commented 2 months ago

Telefónica supports Option 3 (Purpose as Authentication Request Parameter) for the next release, given the existing requirements (see #140). And if more complex scenarios arise in the future, we support Option 4 (Use Rich Authorisation Request to convey purpose) as the preferred option for future releases. But we tend to see the use of RAR as a bit premature for today's needs, it should be considered cautiously. Although we see it as a great option for the future to support scenarios like N-purposes if they are eventually needed. We could keep option 3 as a valid option if there is only one purpose, thus ensuring backwards compatibility.

@jpengar Would you mind to please explain what the disadvantages of Option 1: Purpose as a scope compared to Option 3 (Purpose as Authentication Request Parameter) are? I think both approaches are quite similar in that we have ONE purpose. I think that implementing Option 1: Purpose as a scope is even easier than Option 3, and we do not have to invent a new OIDC parameter. Camara AZ need to implement some special handling because Camara needs purpose. I think it is preferable to have that special handling in a place where some special handling is likely to happen anyway e.g. cases where the client requests one scope which leads to returning other scopes in the reponse.

I view Option 1: Purpose as a scope as a OIDC standard conform way of Option 3. Why not Option 1?

Regarding backward-compatibility, I think that Option 2: Purpose encoded in scope also "works" because it is based on the 0.1 text.

We could change this sentence

"There SHOULD not be two scopes that are the same technical scope for different purposes."

into

"It is required that all <dpvValue> are the same."

Would TEF be OK with Option 2 if the recommendation for ONE scope would be a requirement?

AxelNennker commented 2 months ago

I have sent out a meeting invite for tomorrow to discuss how to proceed with "purpose" and get this PR merged. Hopefully, we do not have to bring this to TSC and have them vote on it. I would very much avoid that. We would all lose.

Please attend the meeting and even better write down your arguments for and against the options here and also your and maybe your company's position. The original meeting invite is here https://lists.camaraproject.org/g/sp-icm/topic/merging_pr_121_purpose/105860869

Elisabeth-Ericsson commented 2 months ago

Ericsson would like to have option 4 as mid-to long term solution but realized that there are strong limitations on the current authZ servers (e.g. Keycloak) to support this. In case of Keycloak, option 4 will not work for the CIBA flow due to strong validation of request parameters on POST and the fact that it is not possible to add new parameters and validation rules. for the very same reason option 3 will not work eitehr.

Thus Ericsson proposes to go with Option 2 and have a limitation for now that only one DVP-purpose value can be used.

AxelNennker commented 1 month ago

The four options can be grouped in two distinct categories:

Extra parameters are hard to implement in off-the-shelf IdPs. So, if you have build your own IdP then supporting a new parameter is easier than if you buy your IdP. The two proposals that fall into the "extra parameter" class are distinguished by whether that parameter is "standard" or not. "purpose" is not-standard, "authorization_details" is standard.

The "no extra parameter" options put "purpose" into the scope values. "purpose as a scope" is also not easy to implement in "off-the-shelf" IdPs.