OIDC attribute ("claim") release best practices

[Paul B. Henson]

I'm trying to decide how to best integrate OIDC claims into my existing idp attribute filtering configuration.

So an OIDC RP can either implicitly request claims by requesting scopes, which can optionally define claims the request covers, or by explicitly requesting individual claims.

In the first case, the RP is only allowed to request scopes which are configured in its metadata (or unverified client policy). As such, any further restrictions in the attribute filter seem redundant, and just using the OIDCScope policy seems appropriate. If it asks for a scope, and that request reaches a filter, it must be authorized to have the attributes, so just let them out with no further questions.

The other OIDC specific attribute filter policy is the AttributeInOIDCRequestedClaims, which is similar to the OIDCScope policy in that it basically says if they ask for it, give it to them. However, I don't believe there are any restrictions on what claims any random RP could explicitly request? So a production configuration like the example shown in the documentation for this policy seems unwise, as the attributes included, assuming they aren't suitable for every possible client, could be provided to every possible client.

For SAML and CAS attribute filtering, I am using metadata driven configuration like:

        <MetadataFilter xsi:type="EntityAttributes">
          <saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
                          Name="http://shibboleth.net/ns/attributes/releaseAllValues"
                          NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
            <saml:AttributeValue>memberOf</saml:AttributeValue>
          </saml:Attribute>
          <Entity>xxx</Entity>
        </MetadataFilter>

  <AttributeFilterPolicy id="memberof_by_tag">
    <PolicyRequirementRule xsi:type="EntityAttributeExactMatch"
                           attributeName="http://shibboleth.net/ns/attributes/releaseAllValues"
                           attributeValue="memberOf" />
    <AttributeRule permitAny="true" attributeID="memberOf" />
  </AttributeFilterPolicy>

As I am keeping OIDC RP metadata in  xml, if I understand correctly, I can do the same thing with OIDC, and just tag them, using my existing policy rules based on tags to release attributes? Are there any reasons this would be a poor choice for OIDC?

Thanks much for any thoughts or comments from your own implementation experiences...

--
Paul B. Henson  |  (909) 979-6361  |  http://www.cpp.edu/~henson/
Operating Systems and Network Analyst  |  henson at cpp.edu
California State Polytechnic University  |  Pomona CA 91768