Relax client assertion requirements and extensibility at Trust Mark endpoints

[Stefan Santesson]

The current requirements on client assertion is excluding any possibilities to offer hosting services for lesser capable federation services.

It has been said in many other discussions here that a lesser capable federation service should be allowed to have its federation data hosted by an Intermediate Entity. This only works if the lesser capable federation entity is NOT forced to use its federation key to sign federation data, or requests for federation data.

As specified today in 8.6.1, any request for a Trust Mark requires a self signed client assertion signed by the subject’s federation key. The rationale for requiring such client assertion is not explained. What is the threat?

• The Trust Mark is NOT bound to the subjects key. It only assert that a subject with a defined Entity Identifier has a valid Trust Mark.
• This Trust Mark is regarded as open information
• Trust Marks are not revoked per issued token, they are revoked per subject

So why is the issuance function of Trust Marks so well guarded ?

‌

The current specification has a field to define client assertion type “client_assertion_type“. This MUST have the value urn:ietf:params:oauth:client-assertion-type:jwt-bearer.

Why have a parameter that MUST have a fixed value?

If you have a parameter here, then I assume that there should be a possibility for another value defined by a profile of this standard? or?

‌

I suggest the following changes here:

• Allow the current client assertion to be signed by anyone (not only the Trust Mark subject)
• Allow the Trust Mark issuer to determine if it wants to accept providing a signed Trust Mark to someone other than the Trust Mark subject (e.g. a hosting Intermediate Entity)
• Possibly define a new client_assertion_type for delegated requests as described above
• Open up for profiles to define other client_assertion_types

‌

‌

[Stefan Santesson]

I think I see now why this got designed the way it is.

This seems to attempt to replicate the structure of client authentication as described in OIDC core section 9.

This is a design that is applicable when the client demonstrates that it is the authorised client for the token endpoint. I fail to see how such client authentication is relevant for a Trust Mark endpoint.

‌

All the Trust Mark contains is public information that a certain subject has a particular Trust Mark. This information is open and published for all to see if you download the Entity Configuration of that subject.

Accessing such Trust Mark is therefore for obvious reason no threat to the system, and requesting a fresh Trust Mark from the Trust Mark Issuer should neither be a security issue.

‌

I think the Trust Mark endpoint could be simplified and inclusion of client assertion could be removed (or made optional).

‌

A radical suggestion would be to simplify the whole Trust Mark process the following way:

• Remove the Trust Mark Status endpoint
• Change the Trust Mark endpoint to be publicly available to everyone, and let it be the means to validate a Trust Mark. (I.e. the way to check if a trust mark is valid if necessary, is simply to ask for a new one from the Trust Mark Issuer)

‌

But I suppose that is too radical at this stage. But I think it would be better and easier validation process.

‌

[Michael Jones]

Hopefully we can discuss this in person next week.

[Stefan Santesson]

Yes, I agree. I hope we can find some quality time to talk about the outstanding issues.

[Vladimir Dzhuvinov]

Duplicate of #2114.