Q1: I’m not sure if I follow the logic here. Assuming we have those
filters, the consent screen will allow user to accept a request with a
filter applied. Even if user stores the decision, it shouldn’t be
applicable for another filter. E.g. if user accepts the request to
release an attribute “permissions“ filtered to a value “read”, then it
does not mean that unity shall release the attribute “permissions” with
filter matching “write”. On another hand, if client has an intention to
preserve the original filter, and consent was stored, then there should
be no interactive ask for which values to release.
That said, I think the Unity-UI controlled selection of active
attribute value can offer a similar feature.

Q2: hmm, I’m confused. So let’s say we have a scope ‘user-info’. There
are 2 claims/attributes released under this scope: ‘role' and 'name’.
Now what filter I can create? “user-info:role“? Or is it “user-
info:role:manager“? What happens with email then?

Answers:

Q1: There is no consent screen involved when the filter is applied. As mentioned in the request:
     "This filter is applied when a new access token is fetched using an existing refresh token, e.g. using oidc-agent: oidc-token -s ..."
    Staying with oidc-agent as the example client application, the consent screen is only shown when "oidc-gen" is called,
    i.e. a refresh token is grabbed by the user, unfiltered. When a fresh Access Token is fetched via "oidc-token" (using the refresh token),
    the filter is applied, but no new consent screen is shown (as claim values are only ever reduced, not extended). This avoids the need for any changes to the UI,
    confusion of UI users (and hence, it prevents flooding operators with support queries), and also answers the implied question as on why the existing UI is not useful for this case. 

Q2:
Antwort sollte nochmal vorab untereinander (TA6 / ...) ausdiskutiert werden.
in der Tat ist das weder im WLCG-Token-Profil noch in unserem Request sauber ausdefiniert.

Zur Erklärung:
Technisch gesehen müssen die "Scopes", die man bei einem Token requested, nicht identisch zu dem "Claim" sein, den man im Token bekommt.
Auch wenn die Namen in der Regel gleich sind, bekommt man in einigen Fällen mehrere Claims (also Felder/Keys im Token) zurück, als man als "scope"s requested hat.
Ein einfacheres (wenn auch nicht praxisnahes) Beispiel als "user-info" ist sicherlich "email". Wenn ich den Scope "email" requeste, bekomme ich im Token die Claims:
"email" und "email_verified".

Eine allgemeine Filter-Logik müsste also entweder:

a) ... rein Claim-basiert sein, dann ist es aber ( in Fällen wo Claim-Name != Scope-Name ) etwas irritierend, dass man das in die Scopes steckt, und man müsste immer den Scope, 
der die Claims "freigibt" mit-requesten.
   Beispiel in der Annahme, ich hätte mehrere Mailadressen im Token:
    oidc-token -s email -s email:o.freyermuth@uni-bonn.de punch-aai
   Das erste "-s email" bezeichnet den Scope "email", der zur Freigabe der Claims "email" und "email_verified" führt, das zweite "-s email:..." bezeichnet hingegen den Claim "email", 
der im Token "durchgefiltert" wird.

b) ... immer Scope, Claim der durch den Scope freigegeben wird, und Value Filter enthalten, also im Beispiel:
    oidc-token -s email:email:o.freyermuth@uni-bonn.de punch-aai
   um "scope email, dadurch freigegebener claim email, darin enthaltenen value o.freyermuth@uni-bonn.de rausfiltern" auszudrücken.
   Daher könnte man sich fragen (brauchen wir allerdings nicht), ob man auch komplette Claims rausfiltern können möchte, also etwa "ich requeste scope email und will nur den claim 
email_verified im Token haben".

Das WLCG JWT Profile[0] umgeht das Problem, in dem nur der Spezialfall "Gruppen" und "scope-Name == claim-Name" berücksichtigt wird, aber ich befürchte, hier sollten wir den Request generisch stellen
statt einen Spezialfall zu schaffen.

Mein Antwortvorschlag wäre daher:

Q2: Thanks for pointing this out. Indeed, the request is not completely clear here.
    Our request is to allow for filtering of claim values only, not full claims. Of course, an implementation covering both would also solve the request (and may be more generic).

    In general, this means there are two possible ways to go about this:

    a) The parametric scope filters the claims directly, i.e.,
       the scope "user-info" triggers the release of the claims "role" and "manager". The "role" claim is filtered, independent from the scope (user-info) which caused the release of that claim. 
So the requested scopes would be:
         user-info role:some_role
       to get all user-info claims and filter the "role" claim with the provided filter via the "parametric scope".
       It may be worthwhile (but not requested by us) to add "role:" as empty filter to "clear out a claim".

    b) The implementation goes the fully verbose way, i.e.:
         user-info:role:some_role
       would yield:
         - All claims the user-info scope provides.
         - The values of the "role" claim filtered with the provided filter.
       You may of course want to add something like "user-info:role:" to clear out that claim (but we would not require it).
       In the cases when a scope exactly matches the claim it exposes, it may be worthwhile to allow collapsing scope into claim (e.g. "eduperson_entitlement:my_entitlement" instead 
of "eduperson_entitlement:eduperson_entitlement:my_entitlement")
       but we would not necessarily request this special case. It would definitely help the most common filter cases, though.

    Both implementations would be fine with the usage scenarios we require.