How to do flattening ?

[rohe]

One of the corner stones of this draft is to allow a trust anchor (federation operator) or for that matter any intermedia entity to limit/restrict the metadata of a leaf entity (e.g. RP/OP).
If for instance the trust anchor decides that the only allowed signing algorithms are elliptic curve algorithms then the evaluated metadata of a leaf entity must only contain such algorithms.

The first attempt at supporting this is what's in the draft right now. A simple system that allows a superior to state the limits of what a leaf entity's metadata can look like.

The reality is of course a bit more complex than what the model assumes.
Take the contacts claim as an example. Here you probably want the subordinates to add their contacts to the ones that are defined by superiors.

Or imaging that a claim (there is none in OP or RP metadata to my knowledge) that has an integer as value. In some cases that value could be something on a scale in which case the superior might want to state you can't have a value >= 10 or < 5. In other cases the value would instead be one in a set and not something you could handle as a something on an ordinal scale.

It would be nice if we could find simple rules one for each value type disregarding what claim it was.
If we got into exceptions (like contacts mentioned above) they would have to be very few anything else would be a disaster.

[alejandro-perez]

We could define a bunch a "policies" for flattening, being the default "is_subset".
Another one could be "ignore", which would mean that any definition in lower MS should prevale.
Another one could be "is_superset", meaning you can add but not remove (eg. imagine a "notification" claim containing a list of emails that should be notified in case of issues).

Finally, we define an additional claim called "policy" being a JSON object, each key is a claim name, and the value is the policy name to apply:

[.....],
"policy": {
   "contacts": "is_superset",
   "a_random_claim": "ignore"
}

This would allow for further policies to be defined.

Just an idea though :)

[alejandro-perez]

I thought of two more: max and min. max is the one applied implicitly to exp, for instance.

[alejandro-perez]

Another one would be frozen/fixed/readonly. Indicating it MUST stay as it is. I.e. cannot be redefined.

[alejandro-perez]

IMO policy should be "is_superset", so lower MS could add policy to undefined claims, but cannot modify those already having a policy.

[alejandro-perez]

Alternatively, if this was desired to allow more complexity, a policy could be a JSON object itself, having a name and a set of parameters, but IMO that would be too much complexity.

"policy": {
   "contacts": "is_superset",
   "a_random_claim": "ignore",
   "some_integer_claim": {"name": "range", "min": 5, "max": 15}
}

[nckroy]

Here is another set of policies:
must_supply_any_value - the claim must be present with one or more values, but the values required are unspecified
must_supply_uri_value - the claim must be present with a value that is a valid URI, values required are unspecified
must_supply_url_value - the claim must be present with a value that is a valid URL, values required are unspecified
must_supply_https_value - the claim must be present with a value that is a valid HTTPS URL, values required are unspecified
must_supply_urn_value - the claim must be present with a value that is a valid URN
must_supply_email_value - the claim must be present with a value that is a valid e-mail address

[nckroy]

These are meant to allow a superior to require specific types of values being supplied, but not what those values have to be. This would support, for example, InCommon's Baseline Expectations program: https://spaces.at.internet2.edu/display/BE/Implementing+Baseline+Expectations+in+InCommon+Metadata

[rohe]

Looks like we're about to define a domain specific language.
Different policies can be applied to claims dependent on the claim value type.
Sounds interesting but complex. Also, I'd like to see how a set of policies defined in entity statements in a trust chain are interpreted. How to 'flatten' policies :-/

[alejandro-perez]

Looks like we're about to define a domain specific language.

Yeah :(. I would not think of it to be that complex, though.

Sounds interesting but complex. Also, I'd like to see how a set of policies defined in entity statements in a trust chain are interpreted. How to 'flatten' policies :-/

In some previous comment I mentioned that "policies" should implicitly be of type "is_superset", so lower MS could add policies, but could not delete or modify existing ones.

But all of this could be defined on a different document. It could even be defined just for a particular federation. Or a federation could just define on their SLA agreements how claims should be flattened (I think we already discussed this in Copenhagen, didn't we?).

In any case, those were my 2 cents :)

[rohe]

I don't believe in federations defining their own flattening functions. That would lead to an interoperability nightmare.
We need one model for how flattening is done.
Now, @alejandro-perez what you propose gets me thinking about claims requests using the claims parameter https://openid.bitbucket.io/connect/openid-connect-core-1_0.html#IndividualClaimsRequests . If we could do something similar to that ...

[rohe]

@nckroy You must remember that a leaf entity in the general case may not know which federations it belongs to (and it shouldn't have to).
Think of it this way: every leaf entity states that this is what I'm able to do, whom ever I talk to and then have the policies reduce this to what actually is going to be used. So having a policy that says you have to have this or you have to have that just doesn't work. For instance, what would the leaf entity do if it belonged to 2 federations with conflicting views on which crypto algorithms to use. One stating that everyone should use RS256 and the other adamant about ES256 being used ? The idea in the draft is that the leaf just states "I can do RS256 and ES256" (provided it can) and then at run time have that statement filtered by the policies such that if you chose to work within federation-RS256 then the resulting metadata statement for the leaf would only list RS256 and vice versa.

[rohe]

Ok, thought a bit more along the claims request path and came up with these examples:

OP metadata policy:

{
  "scopes_supported": {
    "subset_of": ["openid", "email", "profile"]
  },
  "claims_parameter_supported": {
    "value": true
  },
  "op_policy_uri": {
    "default": "https://op.example.com/policy.html"
  }
}

RP metadata policy:

{
  "response_types": {
    "subset_of": ["code", "code token"]
  },
  "grant_types": {
    "subset_of": ["authorization_code", "implicit"]
  },
  "application_type": {
    "value": "web"
  },
  "contacts": {
    "add" : "support@federation.example.com"
  },
  "policy_uri": {
    "add": "https://federation.example.com/policy.html"
  },
  "id_token_signed_response_alg": {
    "one_of": ["ES256", "ES384", "ES512"]
  },
  "token_endpoint_auth_method": {
    "value": "private_key_jwt"
  }
}

The pattern should be obvious. The key words are:

subset_of: Only these values are allowed. If the list of allowed values are ["A","B","C"] and the OP lists ["A","C","D"] as its values. The flattening would result in the set ["A","C"].

value: The value of this claim is fixed to this one allowed value.

one_of: The value of the claim can be one of the listed

add: There is no limitation of which values to use. This value should be added to the resulting list.

default: If no other value is given this one should be used.

Just an idea :-)

[rohe]

Did a Proof-of-concept implementation and this is what I get:

The Federation Operators policy:

{
    "scopes": {
        "subset_of": ["openid", "eduperson"]
    },
    "response_types": {
        "subset_of": ["code", "code id_token"]
    }
}

The organisations policy:

{
    "contacts": {
        "add": ["helpdesk@example.com"]
    },
    "logo_uri": {
        "one_of": ["https://example.com/logo1.jpg", "https://example.com/logo2.jpg"],
        "default": "https://example.com/logo1.jpg"
    },
    "policy_uri": {
        "value": "https://example.com/policy.html"
    },
    "tos_uri": {
        "value": "https://example.com/tos.html"
    }
}

The metadata statement from the RP:

{
    "contacts": ["rp_admins@cs.example.com"],
    "redirect_uris": ["https://cs.example.com/rp1"],
    "response_types": ["code"]
}

And the result after applying the policies:

{
    'contacts': ['rp_admins@cs.example.com', 'helpdesk@example.com'],
    'redirect_uris': ['https://cs.example.com/rp1'],
    'response_types': ['code'],
    'logo_uri': 'https://example.com/logo1.jpg',
    'policy_uri': 'https://example.com/policy.html',
    'tos_uri': 'https://example.com/tos.html'
}