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

More than one "purpose" in an authorization request. #140

Closed shilpa-padgaonkar closed 2 months ago

shilpa-padgaonkar commented 3 months ago

Problem description The OIDC profile PR adds purpose as a transaction specific request parameter, as specified in openid-connect-4-identity-assurance-1_0-13.

This changes the way how purpose was handled in ICM release-0.1.0 where it was declared within the requested scope.

Some colleagues from ICM WG have reservations about this change as they had been presented with a requirement from Open Gateway product team in the past which said that Applications must be able to request access to multiple APIs in the same authorization request. Each API might be consumed with a different purpose. This means that an application could need to declare more than one dpv_value (purpose) in the authorization request.

A single request parameter to specify purpose (as suggested in the PR) would not be able to fulfil this requirement.

Currently, there is no good solution available at hand to fulfil this requirement.

It was agreed in the working group that we will ask for feedback if this requirement is still valid/relevant.

It would be helpful to get feedback from all organizations active in ICM/Camara, and also colleagues from OGW/GSMA if this requirement is still valid/relevant.

Expected action Request members to actively provide feedback in the form of comments under this issue if the above said requirement exists within your respective organizations.

Additional context

gauravji2192 commented 3 months ago

Yes, this requirement exists for aggregator usecases. Client App may request multiple APIs and we don't expect to initiate users to initiate multiple authorization call if they have already authorized once and token is not expired.

AxelNennker commented 3 months ago

Yes, this requirement exists for aggregator usecases. Client App may request multiple APIs and we don't expect to initiate users to initiate multiple authorization call if they have already authorized once and token is not expired.

Is it discussed or documented somewhere that this "mother-of-all-access-token" is quite dangerous and sending it to all resource servers enhances the chance for it to be leaked? Is this already implemented in some markets? Are implementers downgrading the access tokens to less all-empowering scopes using refresh-tokens? https://www.rfc-editor.org/rfc/rfc6749.html#page-47

The steps could be:

  1. request a code for "openid dpv:LegitimateInterest:simswap number-verification:verify"
  2. request a token and refreshtoken for that code (and all scopes mentioned above)
  3. use the refreshtoken to get an accesstoken for a subset of scopes e.g. "number-verification:verify"
  4. use the new accesstoken at the numberverification:verify resource server (and never at the simswap resource server.

That way usage of access tokens at RS endpoints that do not need them is eliminated.

AxelNennker commented 3 months ago

During the TSC meeting we ask for more feedback on this use case. Please add your feedback here.

gauravji2192 commented 3 months ago

No, it is not implemented use case yet. It is more like feedback from user's usability perspective. If user has provided consent once and token is not expired, why they will need to provide authorization if they need to use two API endpoints. Original request from Shilpa in this issue was "Applications must be able to request access to multiple APIs in the same authorization request. Each API might be consumed with a different purpose. This means that an application could need to declare more than one dpv_value (purpose) in the authorization request"

I agree to steps given below:

  1. request a code for "openid dpv:LegitimateInterest:simswap number-verification:verify"
  2. request a token and refreshtoken for that code (and all scopes mentioned above)
  3. use the refreshtoken to get an accesstoken for a subset of scopes e.g. "number-verification:verify"
  4. use the new accesstoken at the numberverification:verify resource server (and never at the simswap resource server.

However, Shilpa mentioned that it is not possible to send two dpv values in one request - "openid dpv:LegitimateInterest:simswap number-verification:verify". If this is possible then it is sufficient.

AxelNennker commented 3 months ago

We are running in circles regarding the various purpose proposals.

I think that restriction of "not possible to send two or more dpv values" in one request comes from some existing implementations. And I guess that if one purpose/dlv leads to a no-user-consent necessary situation and simultaneously user consent is required for a different scope then the consent page gets confusing for the user.

Elisabeth-Ericsson commented 3 months ago

Hi all, the current limit of asking for only one purpose in an authorization request is due to the fact that the consent is given on the pair of <purpose, data scope>. When asking for multiple purposes for the same data scope, it might happen that for purpose1, consent is available but not for purpose2. How should the answer look like ? Solution analysis:

  1. only allow allow one purpose in request, but list of scopes: straight forward, use access token on API call for the purpose in question
  2. allow multiple purpose in request: use opaque access tokens and structures in auth server which manage the pairs of purpose and scope and relate them to consent, send on API call the purpose in question to allow allow picking
  3. allow multiple purpose in request: only grant access token with all combinations of purpose and data scope have consent

Example: Take the example of two purposes (service provisioning and advertising) and two data scopes (data-read, data-write). Then assume that consent is given for both purposes and data-read, but data-write is only given for provisioning. So when calling the API for the write operation, how do I know whether it is permitted or not if I do not know the actual purpose ?

Summary: Solution 2 is for sure possible to solve, but complex and not in line with current standards.
If multiple purposes shall be allowed I only see option 3 possible.

AxelNennker commented 3 months ago

My initial understanding when I joined ICM was that we have purpose encoded in the scope parameter, but somebody said this is not possible or currently not implemented or agreed upon or there are some more requirements.

To write that down again, what I thought was the camara "solution":

Then the AZ can create access tokens for this list of allowed scope parameters. A simple approach for asking for consent could be: There is a text for each scope that is shown the user and they have to agree to all of them.

By clicking "OK" you agree to:
some text regarding p1#t1
some other text regarding p2#T2
...

Deny OK

The RS can validate the access token - does not matter whether the access token is self-contained or not.

if (valid(accessToken, RS_path) then
   do RS_path-specific-stuff
endif

(For billing purposes the RS can log the scope parameters, if there is a way to introspect the access token. The telco implementing the API can log the scope parameters - implicitly logging the purpose)

The above is compliant with OIDC as far as access token issuance at the AZ and usage at the RS is concerned.

The onboarding-of-the-client part is not defined in OIDC.

I see some danger that we end up with a very proprietary AZ and RS implementation if scope parameters are parsed to split purpose and technical scope. But the issuing and usage of the access token can be done with an off-the-shelf AZ and RS without parsing, I think. Parsing out the purposes from the scope parameters is not needed.

Having said the above, I am not sure what part of the above is part of ICM. The onboarding part is not OIDC. If the above is not specified in ICM, then where is it specified?

Elisabeth-Ericsson commented 3 months ago

Hi Axel, this request opened by Shilpa point to a chapter in OIDC profile document, which introduces the SPLIT of purpose and data scope: The OIDC profile https://github.com/camaraproject/IdentityAndConsentManagement/pull/121 adds purpose as a transaction specific request parameter, as specified in openid-connect-4-identity-assurance-1_0-13.

This changes the way how purpose was handled in ICM release-0.1.0 where it was declared within the requested scope. So your assumption on the combination of purpose and scope is not correct any more if the change & evolution proposed in the document is accepted.

I'm fully supporting the change and think that it is much clearer to split data scope and purpose.

In the current V1.0 agreement, there is one purpose before the whole list of dpv values. So, even if you allow a list of dpv values, we would end up with solution 3 - as described above.

AxelNennker commented 3 months ago

Hi @Elisabeth-Ericsson , yes, that is the history and current proposal.

After the proposal to have purpose as split-out, there were concerns that this way we have only one purpose and that there is a requirement that Camara use-cases need more then one. Basically rejecting the current proposal.

I proposed in the meeting (sorry, minutes to be written still) that we use this issue to describe where we are regarding purpose&scopes. The proposal to have purpose as a separate parameter found no big support. Because of the use case that "needs" multiple purposes which leads to terrible UX. So, most probably the proposal is not going to stay in the profile.

So, today I wrote down what initially understood and which I think "technically" works - OIDC-wise. In one sentence: Access token issuance and usage is OIDC compliant with purpose and scope combined in scope parameter while onboarding is not necessarily an ICM matter.

Let's run through the circle one more time, look what we can agree on.

sebdewet commented 2 months ago

Hi, that's also our understanding on Orange side.

The scope’s parameter needs to contain the couple purpose-scope, and each purpose-scope the user hasn't accepted or revoked must be asked when consents are asked to the End-User (after authentication).

Then the token generated will embed the purpose-scope in the scope’s parameter that has been accepted by the End-User. End-User can for example accept dpv:FraudPreventionAndDetection#number-verification:verify but deny dpv:FraudPreventionAndDetection#number-verification:device-phone-number:read. Same purpose, different scope, and the RS will know during the introspection that Client only have access to check the MSISDN.

Elisabeth-Ericsson commented 2 months ago

@sebdewet: From your description I understand that your proposal is to allow a list of pairs \<purpose>#\<data-scope>.

There are examples where this approach will lead to unclear situations on API invocation, unless the current "purpose" is conveyed on the API invocation in addition. Example: KYC API exposes two data scopes:

When calling the read operation of the API, how should the logic in the API determine, which data scope to expose ?

So either we must prevent/forbid having two different data scopes for the same operation on an API or we need to find a way to send the current purpose in question when calling the API (which is not in line with the standard).

AxelNennker commented 2 months ago

Maybe the problems we are facing stem from the fact that there is some disconnect between the API specification in an API working group and onboarding time addition of purposes.

In OpenApi each path can have a security requirement object.

Picking up @Elisabeth-Ericsson 's example (as I interpret it):

...
paths:
  /read:
    get:
      security:
        - openId:
          - customer-identifiers:read
          - customer-address:read

...

OpenAPI says: If the security scheme is of type "oauth2" or "openIdConnect", then the value is a list of scope names required for the execution

So, the above openapi.yaml fragment means that both scopes are REQUIRED (regardless of purpose). Simply prepending purpose to the technical scopes would lead to 

...
paths:
  /read:
    get:
      security:
        - openId:
          - dpv:EnforceSecurity#customer-identifiers:read
          - dpv:EnforceSecurity#customer-address:read
          - dpv:CustomerManagement#customer-identifiers:read
          - dpv:CustomerManagement#customer-address:read

...

All of these scopes are now required for the execution of /read, which means if the user declines consent to one scope, then the RS rejects "/read" for that an access token that has only three of the four scopes.

Which might make sense in some businesses where to fulfill a contract the user has to consent to all the scopes.

I think in openapi there is no way to say: "for this path the API behavior depends on whether one specific scope is 'in' the accesstoken". All required scopes are required. (Pulitzer prize for that last sentence)

The question is which openapi specification do we communicate to the client. Latest at onboarding-time the client might need to know which purposes are available and allowed for them and which they pay for.

Or do we have something like this openapi spec returned at onboarding time to the client?

...
paths:
  /read__dpv:EnforceSecurity:
    get:
      security:
        - openId:
          - dpv:EnforceSecurity#customer-identifiers:read
          - dpv:EnforceSecurity#customer-address:read
  /read__dpv:CustomerManagement:
    get:
      security:
        - openId:
          - dpv:CustomerManagement#customer-identifiers:read
          - dpv:CustomerManagement#customer-address:read

...

The client knows which scopes are in the access token because the AZ returns the granted scopes if they list of granted scopes is different from the requested scopes. So, the client is not surprised if scopes are missing. Of course the client might then not be able to fulfill their contract with the user.

Regarding the RS: Whether the RS can "get" the scopes "in" the access token is implementation specific. And if the RS "knows" the individual scopes then the RS can return scope-specific responses. That can't be formalized in an openapi spec, though, I think. scope in openapi decides whether a request is authorized or not, it does not change the response.

palmerabollo commented 2 months ago

Trying to recap, I believe there are two options in the table, depending on whether we aim to support tokens with multiple purposes (i.e. multiple reasons for accessing certain personal data), which appears to be a tradeoff between user experience (UX) vs. simplicity/security.

OPTION 1. Use a separate "purpose" attribute

It is the simplest option. It is valid if there is no need to send more than one purpose in the same authorization. Otherwise a developer would need to request more than one token. For example:

GET /authorize?scopes=device-location-read check-sim-swap openid&purpose=dpv:FraudPrevention&...

OPTION 2. Use scope prefixes (dpv:xyz#scope) to support for multiple purposes

For instance, if an application wants a token with a scope from the Location API (for marketing purpose) and another scope from the Sim Swap API (for fraud prevention):

GET /authorize?scopes=dpv:Marketing#device-location-read dpv:FraudPreventionAndDetection#check-sim-swap openid&...

An application cannot request the same scope with two different purposes. Otherwise it would be impossible to know which specific purpose is being used when calling an API as Elisabeth described. An example of an incorrect request would be:

GET /authorize?scopes=dpv:FraudPreventionAndDetection#device-location-read dpv:Marketing#device-location-read openid&...

Added complexity makes it unclear how to deal with partial consents as Elisabeth also explained. What if user grants consent for one purpose and not for the other? I also think that, if we choose this option, it should be an all-or-nothing approach.

Both options remove the restriction in ICM release-0.1.0 because devs can request scopes from different APIs without explicitly mentioning the API name(s), and also to identify the specific purpose for each scope.

IMO we should default to simple unless there is a clear requirement coming from OpenGateway product track or any other forum. It's easy to move from option 1 to option 2 in the future, but not the other way around.

Elisabeth-Ericsson commented 2 months ago

Hi all,

I want to bring one more aspect to the discussion. In my view we must avoid - under all circumstances to include the purpose values into the API specifications. This will be unmanageable over time. When we go for option 1, this will come out of the box. When we go for option 2 at some point, we need to find a way to avoid the conflicts, e.g. do all-or-nothing for multiple purposes.

When going for a format of combining purpose and scope, we must avoid to ask for the same scope for two different purposes. We can still go for a concatenation in the token request, but this concatenation must not be part of the yaml file.

IMO, we should start with option 1.

AxelNennker commented 2 months ago

My summary: We see the UX topic but do not have a clear business requirement. We asked several times for comments on this issue providing business requirements (or not). I asked at Camara all-hands and at TSC meetings.

@gauravji2192 , @jpengar, @Elisabeth-Ericsson +1-ed @palmerabollo 's comment and preference for Option 1 (for now). @sebdewet Orange seems to prefer Option 2. Maybe Orange can agree to have Option 1 in the current text and agree that we discuss moving to Option 2 in a later version?

If Orange agrees, do we then keep @shilpa-padgaonkar text and close this issue?

Purpose

A transaction specific request parameter purpose as specified in openid-connect-4-identity-assurance-1_0-13 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

Although, I suggest re-phrasing that text a little to:

Purpose

An OPTIONAL transaction specific request parameter purpose as specified in openid-connect-4-identity-assurance-1_0-13 allows the client to state the purpose of the requested scopes.

The purpose string MUST use below format for interoperability

dpv:<dpvValue>

<dpvValue> is coming from W3C DPV purpose definition

jgarciahospital commented 2 months ago

From a pure product perspective, Telefonica's preference would be to allow multiple couple scope-purpose (option 2) as the most wide approach for adapting the usage of tokens.

@sebdewet, totally agree with your approach.

Hi, that's also our understanding on Orange side.

The scope’s parameter needs to contain the couple purpose-scope, and each purpose-scope the user hasn't accepted or revoked must be asked when consents are asked to the End-User (after authentication).

Then the token generated will embed the purpose-scope in the scope’s parameter that has been accepted by the End-User. End-User can for example accept dpv:FraudPreventionAndDetection#number-verification:verify but deny dpv:FraudPreventionAndDetection#number-verification:device-phone-number:read. Same purpose, different scope, and the RS will know during the introspection that Client only have access to check the MSISDN.

@Elisabeth-Ericsson, agree with you about decoupling the purpose definition to the API spec, in fact that is why generic W3C purposes are promoted instead of creating ad-hoc for CAMARA. Whis this decoupling, we do have 2 separate sets of standard identifiers that jointly create a wide and adaptive usage of the APIs:

We just need to enable a mechanism to allow combining them in the same token, of course, defining strict rules (below).

Including only one purpose for a hole set of scopes in the same token will restrict to minimum the number of scenarios where one single token can be used to access more than one API (more than one scope), while reality shows that heterogeneous APIs will be required to be used together, e.g. Number Verification for antifraud while location for service provision and carrier billing for payment. Real example out of many others that cannot be handled with a single purpose.

Speaking about restrictions, it's clear that:

  1. Each couple purpose-scope will require its own lawful base treatment. Consent, legitimate interest.. will require different treatment and considerations, and a different acceptance (automatic or not) will therefore imply that the token will finally only be valid for those "couples" that are accepted. But it is important to remark that this same issue will appear in the single purpose approach, since same purpose applied to different APIs/scopes will indeed also require different lawful basis and different acceptance.
  2. As per usage identification, it is clear that a token containing 2 couple of the same API but for different purpose need to be prevented. Simply because operator cannot know for which of those purposes it is being used, so charging, auditing or even lawful basis access control could not be executed if that situation appears.
  3. If some APIs require a specific access token creation mechanism, it is also clear that being contained in a group shall not allow them to be retrieved with other mechanism. E.g. Number Verification can only work as part of an AuthCode flow, so a group of scopes:purposes including NV can only be triggered based on an authcode flow. Again, this restriction should apply to any of the two options.

Apart from those, developers will be able to use any purpose and scope within the same access token (from those that operator is, of course, offering) and therefore optimise the access to APIs employing a single token instead of 2, 3,4... again, just because the heterogeneous APIs/services handled in CAMARA is clearly targeting also heterogeneous purposes.

shilpa-padgaonkar commented 2 months ago

I support to start with option1 for now as mentioned above also by @palmerabollo @Elisabeth-Ericsson

If we want to later address complex combinations, IMHO we might want to look at RAR

eric-murray commented 2 months ago

@AxelNennker I would avoid using the OpenId Identity Assurance specification as a reference for the purpose parameter of Option 1 (as described in this comment) as the specification also defines purpose as an extension of the claims parameter as defined by the OpenId Core specification.

Copying the example, claims would be extended to include purpose as follows:

"claims": {
  "given_name": {
    "essential": true,
    "purpose": "To make communication look more personal"
  },
  ...
}

Applying this to the CAMARA context for the proposed text, and assuming that, for CAMARA, a claim is equivalent to a scope, I therefore might expect the purpose for requesting a given scope to be specified as follows:

"claims": {
  "sim-swap:check": {
    "essential": true,
    "purpose": "dpv:FraudPreventionAndDetection"
  },
  ...
}

But that is not how I understand Option 1 at all, which I interpret to be adding purpose as an additional query parameter for authorisation code flow, or additional form parameter for the CIBA flow, e.g.:

Authorisation Code Flow

GET /authorize?scope=openid%20sim-swap:check&purpose=dpv:FraudPreventionAndDetection&...

CIBA

   POST /bc-authorize HTTP/1.1
   Host: server.example.com
   Content-Type: application/x-www-form-urlencoded

   scope=openid%20sim-swap:check&
   purpose=dpv:FraudPreventionAndDetection&
   login_hint=...

So if my understanding of Option 1 is correct, then no reference to the Identity Assurance specification is required at all, as that defines a different mechanism for passing purpose.

And if my understanding of Option 1 is not correct, then I anyway need a much better description before I can agree to it.

sebdewet commented 2 months ago

@sebdewet Orange seems to prefer Option 2. Maybe Orange can agree to have Option 1 in the current text and agree that we discuss moving to Option 2 in a later version?

If Orange agrees, do we then keep @shilpa-padgaonkar text and close this issue?

Hi, Orange issue is that purpose outside of scope isn't OIDC standard, and we will need to obtain a validation for this modification of the standard, then implement it in the existing authorization servers.

If we pushed to add purpose in scope, it was to keep the OIDC standard, and to bring this evolution without modifying anything, aknowleding the fact that to get purpose was a good idea.

I don't really understand the difference between the option 1 and 2, except that option 1 need to add a purpose parameter (which is binding). The only goal is to check that we will only have one purpose for each authorize request ? We can also check in the scope parameter that we have only one purpose between each "dpv:" and "#" ? (If I understand the option 1 as @eric-murray)

AxelNennker commented 2 months ago

@sebdewet We were running in circles with the purpose discussion. Yes, we could "code" purpose into scopes and that is what we had in 0.1 but that has some limitations. So, after arguing is circles for some time, we thought that re-using the purpose parameter as defined in eKYC-IDA Transaction-specific Purpose would be a simple step forward and clearly state what the purpose of the request was. Nothing more from eKYC-IDA is "borrowed".

Yes, that adds a new parameter but that is what "profiles" can do.

All agree that Camara needs the ability to express "purpose". Re-using the already in eKYC-IDA standardized parameter purpose for Camara seems a reasonable, small but meaningful step forward.

sebdewet commented 2 months ago

@sebdewet We were running in circles with the purpose discussion. Yes, we could "code" purpose into scopes and that is what we had in 0.1 but that has some limitations.

Hi, sorry, perhaps you already detailled it, but could you specify all the limitations that the option 1 would answer to and not the option 2 ?

we thought that re-using the purpose parameter as defined in eKYC-IDA Transaction-specific Purpose

Purpose has been removed from the latest version of this specification . It will be added in a separate draft : "Removed "transaction specific purpose" from IDA spec with intent to create separate draft" thus we can't rely on this spec version.

hdamker commented 2 months ago

@sebdewet We were running in circles with the purpose discussion. Yes, we could "code" purpose into scopes and that is what we had in 0.1 but that has some limitations.

Hi, sorry, perhaps you already detailled it, but could you specify all the limitations that the option 1 would answer to and not the option 2 ?

The main arguments I see:

Said this I would have really hoped that we will go with Option 1 within the initial profile. Now we are mostly thrown back to the short-term compromise within ICM v0.1 which is not only restricted to one purpose, but also more or less to one scope due to the undefined semantics of multiple purpose#scope pairs.

we thought that re-using the purpose parameter as defined in eKYC-IDA Transaction-specific Purpose

Purpose has been removed from the latest version of this specification . It will be added in a separate draft : "Removed "transaction specific purpose" from IDA spec with intent to create separate draft" thus we can't rely on this spec version.

You are right that we can't use these exact reference any more. But my understanding is that the group is still following the same approach, that they just decide to carve it out into a separate document (which make sense, as the purpose definition will be needed in different contexts).

shilpa-padgaonkar commented 2 months ago

This issue was created so that we could get some feedback from the OGW product team if the requirement to support multiple purposes in a single auth request is still valid or not. Our colleagues from TEF were kind to send out a separate email to the participants of the product team to react to this issue.

As there has been no feedback on this, can this issue be closed with the conclusion that currently Camara will ONLY support one purpose per auth request and if there is such a requirement coming up at a later point in time, a new issue will be created for it?

@AxelNennker and @jpengar WDYT? Or was this already discussed in the last ICM meeting (sorry I missed it) and we already have some other decision in place?

jpengar commented 2 months ago

This issue was created so that we could get some feedback from the OGW product team if the requirement to support multiple purposes in a single auth request is still valid or not. Our colleagues from TEF were kind to send out a separate email to the participants of the product team to react to this issue.

As there has been no feedback on this, can this issue be closed with the conclusion that currently Camara will ONLY support one purpose per auth request and if there is such a requirement coming up at a later point in time, a new issue will be created for it?

@AxelNennker and @jpengar WDYT? Or was this already discussed in the last ICM meeting (sorry I missed it) and we already have some other decision in place?

@shilpa-padgaonkar 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) 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.

sebdewet commented 2 months ago

Hi, really sorry for the delay.

  • Option 2 will not only require a change of AZ to handle the purpose in every scope, but also a change of every RS to understand that it necessary to strip of the dpv value to get the actual technical scope defined in the API. With option 1 the RS could have ignored the purpose.

AZ can also delete the purpose in the scope as soon as the consent has been obtained from the End-user. RS won't have to deal with the purpose. We want to add purpose in order to show the End-user why he gives his consent for, it means that it's not longer useful when consent has been given ?

  • Option 2 is not extensible - e.g. it will never allow to differentiate between mandatory and optional purposes and/or scopes within a request (to present it accordingly to the end user who has to give the consent) like eKYC-IDA did with the purpose field within the claims parameter to differentiate between essential/non-essential and to have different purposes for single claims. I don't argue to introduce such complexity now, but by following them we would have kept the way open.

We defined during ICM meeting that a specific scope could be linked to only one purpose, thus a single claims won't have to deal with several purpose

  • With the current status of discussion we don't have in Option 2 the semantic of multiple pairs of purpose#scope defined. E.g. how to present these and how to handle partial consent is not defined and will lead to different implementation -- there were some ideas mentions but nothing thought to an end. That defeats the purpose to support (potential) business use cases with multiple purposes already within the initial version of the profile.

You're right, there is still things to define

You are right that we can't use these exact reference any more. But my understanding is that the group is still following the same approach, that they just decide to carve it out into a separate document (which make sense, as the purpose definition will be needed in different contexts).

Right, and as soon it will be specified and standardized, Orange will see how to implement it.

I am sorry for the exchanges on this subject, it gives the impression that I am blocking progress. This is not at all my intention, I just mention the alerts of the functional experts of our AZ group solution and their reluctance to implement solutions that are not standard and the risks that this implies on CAMARA.

@shilpa-padgaonkar and @hdamker, you discussed with @bigludo7 yesterday and talked about RAR. I try to convince that it would be a better way to implement purpose than in scope to our AZ functionnal experts. But it's currently difficult to discuss with them currently has it's hollidays and non-working days right now.

shilpa-padgaonkar commented 2 months ago

@jpengar @sebdewet @Elisabeth-Ericsson @AxelNennker : From all the latest comments under this issue, it seems that we are all in agreement that we restrict the authorization request for now to one purpose. After the release 0.2.0, when needed, a new issue can be created to handle complex cases such as multiple purposes in a single auth request.

With this comment, I will now close this issue.

All other discussions about how to represent purpose can be done as usual with comments under PR #121.

Thank you all for providing your feedback on this issue.