OIDC in 4.1.0 and problems with claims

[Darren Boss]

RIght, it wasn't in the docs but in the comment above the
idp.oidc.encodeConsentInTokens line in oidc.properties
# Store user consent to authorization code & access/refresh tokens
instead of exploiting consent storage

I am using default/client-side consent options, nothing with
idp.consent in my idp.properties has been uncommented.

So, try setting encodeConsentInTokens to true and enabling the consent
post login flow again?

On Tue, Apr 6, 2021 at 4:27 PM Cantor, Scott <cantor.2 at osu.edu> wrote:
>
> On 4/6/21, 4:25 PM, "users on behalf of Darren Boss" <users-bounces at shibboleth.net on behalf of darren.boss at computecanada.ca> wrote:
>
> >    Your comment about "you can also toggle an option to store the record
> >    in the access token" rings a bell. I did come across that somewhere in
> >    the docs. My goal is to get attribute release consent working for at
> >    least a subset of my registered OIDC clients.
>
> It wasn't actually documented (came late), other than the javadocs.
>
> Once it's clarified/confirmed we can certainly add to the docs, but as I say, if you're using client-side storage for consent, I would think it's clear that would be...problematic? But there is a workaround.
>
> Probably we need a separate discussion of consent for the docs rather than try and alude to all this in other places...
>
> -- Scott
>
>
> --
> For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net



-- 
Darren Boss
Senior Programmer/Analyst
Programmeur-analyste principal
darren.boss at computecanada.ca