Entity registration policy

[Razumain]

This is an open discussion topic. I'm not 100% clear of whether this should be adressed, or in what way.

We are having a lot of discussions how to introduce a more collaborative infrastructure in Sweden where we can may see emerging OpenID federation islands, where we eventually want to create bridges through cross linking.

OpenID federation gives us most of the tools we see a need for that, but one piece seems missing. We identify the main responsibility for an Intermediate to check the identity and the federation key of a registered Entity. Trust Marks are handled by Trust Mark Issuers, and the metadata is submitted and signed by the Entity itself. All works as long as the identity and key are validated.

However, we may face a situation where this is done to vastly different security levels. Currently there is no way to learn what type of checks to what level of security that was applied by the Intermediate.

If such declaration was possible, we could apply constraints on chains to only include subordinate statements that meets certain criteria. I think that could be very valuable.

Has anyone else had thoughts in this direction?
What did you conclude?
Should something be added to the core document, or should we rely on custom claims?

[rohe]

Having been immersed in SAML2 federations for ages this problem set is not new to me. :-)
It has some similarities to the concept of Identity Assurance Levels.
Just a thought.

[selfissued]

You're wanting statements about the level of security applied, Stefan. What would those statements look like?

[Razumain]

I'm not proposing anything at this moment. I have identified a potential need. First step is to see if there are more seeing this need and to discuss possible solutions.

I think this one could be important though.

A solution could look like the following:

• Define a Subordinate Statement claim like "registration_policy" holding a URI identifier
• Add a new constraints type to 6.2 where you can constrain on permitted or excluded policies

All of this could be done in a profile without breaking the current spec. However, I think this would benefit from being standardized if included.