Request information about AttributeQuery usage and OIDC support

[Cantor, Scott]

As a general matter, the IdP isn't a provisioning engine (deprovisioning being part of that). We're not trying to solve that problem. We don't have the resources for that and there are already tools for that problem in the same ecosystem, Grouper primarily.

There aren't any material changes to Attribute Query support in V5 (or likely ever, it's very stable code). Anything that used to work is going to work fine now, or a bit better as other enhancements apply.

As I recall people used to propose doing queries to probe for liveness, and that's certainly at their discretion, you can configure the IdP to do that, certainly. But that's not a thing that services just do, and so it's probably not of widespread interest when things just don't work off the shelf doing that sort of thing.

OpenID essentially does some of that sort of thing itself, that's what the whole token dance and UserInfo endpoint is for, and tokens can last as long as you configure them to. But whether a client really can handle all that or treat the results in a useful way is up to the client.

The resolvertest endpoint is for debugging, it isn't meant to be exposed, though I suppose given a service account it could be configured in a way that would serve a similar purpose, but like SAML queries, it's not token based, it's "do I have the credentials to call it and an identifier that will resolve?".

> 6.) Is there any information whether and how the OIDC
> support will be improved in Shibboleth?

Anybody can file requests for enhancement, and we take member requests far more seriously than the rest, as we should.

There's far more in our OIDC feature set than 99% of the adopters are making use of as it is. There is a clear point of "let's stop piling on until it's clear where the demand really is".

Spending time on tools for configuration management  and on the documentation are probably much better uses of time.

-- Scott