Hi, Aljaz. First of all, when we are talking about release of user data in OIDC, we are talking about claims. Scopes are used in initial request for convenience, scope just "points" to a group of claims related to each other in some way. In dynamic scope script you manipulate individual claims, not scopes. Idea behind dynamic scope is that if such scope's name is encountered in request, corresponding script is executed, which can change list of claims in a lot of ways. Then this updated list will be released, usually from `/userinfo` endpoint. >By 'dynamic' I mean scope name that is different with every request. There may be a problem. Gluu server won't process scopes which are not allowed to be used by this particular client in some way. This means any scope must be added to list of client's allowed scopes before it will be acknowledge anywhere in its flows. You can access your undeclared scope from consent gathering script as due to its nature this one tries to provide complete list of parameters used in a request. If you insist on this approach, how about adding a custom attribute to all your user entries, to which you'll be storing your scope's name from consent gathering script (may be with a timestamp of some sort, to be able to distinguish stale records), and then read it in your dynamic scope script? I also think there should be some way to read initial request parameters from dynscope script as well, may be you should research this approach as well. Please also note that free community support doesn't include assistance with scripting, so we won't be able to provide you too much assistance with this task.

Hi Aliaksandr, > ... how about adding a custom attribute to all your user entries, to which you'll be storing your scope's name from consent gathering script ... I can set the value of custom attribute in consent gathering script (user.setAttribute()), but the value of the attribute is gone by the time dynscope script is run. I don't know how I can make the attribute value persistent. Please correct me if I'm wrong, but the way I understand your suggestion, this would require that value (payment id) of this custom attribute is updated in LDAP every time a new request is made. I don't think this is right way, as the value of payment id is specific to request, not user. How could then a user have two outstanding requests (two consents, two payments) at the same time? Sure, I could store two attributes. But how can I know which attribute belongs to which request? Also, I believe often changing the attribute value could cause consistency issues when load-balancing is used. > ... there should be some way to read initial request parameters from dynscope script as well ... I was unable to find a way to to that. Can you please provide some additional info?

Hi, Aljaz. >I can set the value of custom attribute in consent gathering script (user.setAttribute()), but the value of the attribute is gone by the time dynscope script is run. That's strange. Perhaps you don't finalize the process, so it's never written to LDAP db. You could check how it's handled in custom scripts which enrol/update user entries, like [this one](https://github.com/GluuFederation/oxAuth/blob/master/Server/integrations/saml/SamlExternalAuthenticator.py#L285) >Please correct me if I'm wrong, but the way I understand your suggestion, this would require that value (payment id) of this custom attribute is updated in LDAP every time a new request is made. I don't think this is right way, as the value of payment id is specific to request, not user. How could then a user have two outstanding requests (two consents, two payments) at the same time? Sure, I could store two attributes. But how can I know which attribute belongs to which request? You could invent some kind of protocol, store data structures, like JSON in those attributes, with a metadata of some sort, which will help to distinguish them. I'm not saying it's the best and most efficient approach, it's just a relatively easy (and crude) solution which comes to mind right away. We can't offer you a better one without dragging in our developers, and this is not allowed within Community Support, with a few exceptions. This discussion already starts to involve quite in-depth subjects we can't afford to assist you with at Community support, unfortunately. All Gluu's codebase is available for study, so you should find some way to achieve what you need. If you would like to have support from our developers on this, please consider purchasing a support plan. I'm closing the ticket for now.

We have an enhancement request already for this feature: [oxauth-839](https://github.com/GluuFederation/oxAuth/issues/839)