[EXT] OIDC attribute/claim inclusion in id_token

[Scott Cantor]

> Ah, interesting; I didn't realize that. I don't recall seeing that in the documentation, at least explicitly.

The properties ought to say something or other to that effect if they don't, probably should just say "globally" control XXX profile setting.

> Are there any examples anywhere of setting it on a per relying party basis, or is that left as a lesson for the reader :)?

Same as SAML, create RelyingParty overrides with dedicated profile beans, or use metadata tags.

> We do use metadata driven configuration on our SAML metadata, and also use the OIDC.*.MDDriven beans in our relying-party.xml configuration. I don't see them listed on the metadata driven configuration page?

That's core IdP documentation. The OPProfileConfiguration page has the plugin details on that, namely the profile IDs for any tags.

> Extrapolating, my best guess would be something like this? Close :)?

Multiple values for a list setting are multiple value elements, not delimited.

I don't know the profile IDs offhand, but in any case, it's always possible to just do a tag that is "cross-profile", it rarely matters that a tag is specific to one profile anyway.

This setting shiould be on the authorization endpoint profile, anyway, so it wouldn't be that one.

> Out of curiosity, am I correct in my interpretation of the specification that if they want these attributes in the id_token they should be asking for them explicitly rather than requiring us to do a kludge like this?

I don't think the id_token response type is specifically focused on changing the content of the token, that's more about avoiding the code exchange, i.e. it's the implicit grant flow. Becuase there's no access token, it can't access the UserInfo endpoint, so there's no choice. Just a side effect really.

But in a sense, if you're not going to use the tokens, yes, implicit is just better, IMHO. Implicit allows SAML-like testing from QA systems, which I consider a key requirement for deployability of integrations. If I can't test it, I can't support it.

-- Scott