Migrating to duende from IDS4 - question about any resolution to updating claims on introspection with reference tokens

[AlexSapple]

Which version of Duende IdentityServer are you using?
N/A - looking to migrate shortly (currently using IDS4.1.2)

Which version of .NET are you using?
.Net6

Describe the bug

Currently, I have an issue in IDS4 - and I am wondering if there has been any changes in the area under Duende. Knowing this would give me the ammo I need to expedite the migration and get it scheduled sooner in my org...

Using Code grant application_code with reference tokens - on introspection, I am unable to update claims - that is, the method GetProfileDataAsync() of a customIProfileService isn't called. The IsActive is called, but the context passed in that method isn't suitable for changing claims (and it sounds like hack attack to try and tweak stuff at that point!) - so I am wondering if this behavior is any different in up to date versions of Duende - any feedback would be really great.

To Reproduce
N/A

Steps to reproduce the behavior.
N/A

Expected behavior
N/A

A clear and concise description of what you expected to happen.
Ideally I want a mechanism to allow me to alter a users claims on the fly during introspection - I could be wrong but I think this is the most suitable time since introspection is going to happen on each use of the token - this means I can get the claims updated for the logged in user as they continue to use the existing token.

Log output/exception with stacktrace
N/A

Additional context

Add any other context about the problem here.
N/A

[brockallen]

Nothing significant has changed in this area. The fundamental issue is that on all other requests to the profile service, the user's claims from the original login session in the UI are present. On introspection, since the only thing presented is the access token, then that original context for the user is not present anymore and the only claims present for introspection are those in the access token.

We could possibly look into somehow making the original user's session as part of the reference token stored in the DB, but this would likely be a breaking change. We'd not be able to consider this until a v7.0.

[AlexSapple]

ok, thanks @brockallen - I appreciate the quick answer.

I'll close this ticket for now as that question is answered. (and our org will be migrating anyway as we get around to it... along with the 1 billion other tasks that keep us busy every day :)

all the best.