OIDC in 4.1.0 and problems with claims

[Cantor, Scott]

On 4/7/21, 9:12 AM, "users on behalf of Darren Boss" <users-bounces at shibboleth.net on behalf of darren.boss at computecanada.ca> wrote:

>    So client side storage of attribute release consent is not practical
>    for OIDC or in any context? It doesn't work well because people may
>    use different clients/browsers? I guess I need more context.

Different browsers, constantly clearing state because every Help Desk treats that as the modern "have you tried turning it on and off?" response, different devices in partciular (phone, tablet), ad nauseum.

Using it for sessions works fantastically. It's probably the best thing I've ever built. For consent? Not really. It's an exietence proof that the generic storage model I built actually works, and it's great for testing of course, but not much else.

>    I currently have two instances of the IdP running and use cookies for
>    sticky sessions so I have the problem that anyone has when running a
>    clustered IdP. It's probably overkill to run multiple replicas in our
>    case but it does help when rolling out a new configuration or a
>    newer/rebuilt container since there will always be at least one
>    instance running at all time.

Sure. And state is a nightmare. Ergo, I don't support consent. No free lunch, and the price of this one is way more than I'm willing to pay.

-- Scott