[Openid-specs-ab] Issue #2107: Relax client assertion requirements and extensibility at Trust Mark endpoints (openid/connect)

[Stefan Santesson]

New issue 2107: Relax client assertion requirements and extensibility at Trust Mark endpoints
https://bitbucket.org/openid/connect/issues/2107/relax-client-assertion-requirements-and

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

‌

‌