That was me not testing, I used the Scoped encoder but left the definitions as Simple. Just pushed that fix.

Installed the current version of the OP plugin to a fresh 4.1-SNAPSHOT with the following logic:

1. sh bin/plugin.sh -i idp-plugin-oidc-op-distribution-3.0.0-SNAPSHOT-bin.tar.gz —verbose --noCheck

2. manually fixed idp.oidc.issuer on conf/oidc.properties

3. manually fixed static/openid-configuration.json (hostname in the URLs)

4. enabled OIDC profiles in conf/relying-party.xml

5. un-commented the ExampleFileResolver on conf/oidc-clientinfo-resolvers.xml and populate test RP metadata

6. edited conf/services.xml to contain references to oidc-attribute-resolver.xml, oidc-attribute-filter.xml and oidc-credentials.xml

7. created the JWK credentials for RS/ES signing and encryption

For OIDC subject to work, I had to manually change the *oidcext:OIDCScopedString* encoder to *oidcext:OIDCString* on *conf/oidc-attribute-resolver.xml* (attribute id=subject). I'll create a separate issue regarding that, as clearly the scoped string should also work there.

With those steps, a simple login use case with Apache mod_auth_openidc was successful.

The attribute resolver example has been streamlined and a set of default claim rules are drafted.

My philosophy was to use existing attribute ID conventions from our existing rulesets where possible and then add claim rules for the rest of the OIDC default claim rules and a few eduPerson attributes.

The stuff we don't have existing analogies for I just used identity mappings for (i.e. attribute ID == OIDC claim name).

The eduPerson cases that don't fit standard claims I used the more obvious mapping, which is obviously just the friendly name / LDAP name. I see no logic behind making eduPersonPrincipalName into eppn or even worse something like eduperson_principalname.

MDDriven wiring is done for existing options.

Starting to work on wiring in MDDriven profile config support, 3 of them done and tests passing.