[Openid-specs-ab] Key Management challenges with OpenID Connect Federation 1.0 - draft 00

[Roland Hedberg]

> 27 juli 2016 kl. 04:25 skrev Mike Schwartz via Openid-specs-ab <openid-specs-ab at lists.openid.net>:
> 
> OpenID Connect gurus:
> 
> I have many comments on the "OpenID Connect Federation 1.0 - draft 00", but I'll start at this design question: Is this proposed trust model too complicated?
> 
> Although key management is a well defined domain, in practice organizations have significant challenges managing keys. There are a lot of keys sprinkled around the organization, in a lot of formats.
> 
> If I am reading this proposal correctly, it suggests adding three long lived keys: one each for the developer, RP and OP.
> 
> 1) Is this really a good idea?

I, no surprise thinks it’s necessary.
I don’t believe that you can get away with running centralized identity federations much longer.
So far we’ve done that but that is only because we haven’t reached any major scale yet.
If identity federations are going to live and prosper I think we need a system that allows for 
centralized management when necessary and decentralized when needed.
In the next version of the draft there is better support for choosing one or the other.
 
> 2) OpenID Connect key rotation is frequent. But the suggestion here is that the federation keys would be infrequently / never updated. Why the dichotomy? Inevitably when key rotation is required, what is the impact?

In the following I’m only talking about the signing keys that are part of protecting the metadata not about the 
keys that are use in the normal OIDC communication.

There is a trade-off between infrequent and frequent signing key rotation.
The lifetime of a client registration can not exceed the lifetime of the keys used to secure the content of the metadata
the same goes for the lifetime of the discovered OP configuration.
So if the signing keys lifetime is short then the client will have to re-register and/or do configuration discovery frequently .
On the other hand if sometime is ’wrong’ with the RP/OP then you want to block it as soon as possible which means
you want a short lifetime of the registration/discovery.
If an OP has few clients talking to it then the client registration lifetime may not be a big issue, if it has plenty of
clients having them reregistering often may be a real burden.

> - Mike Schwartz
> 
> PS: There are many distracting typos. Is there a place to submit pull requests so I don't waste time posting spelling corrections on the list?

The next version which I hope to get out next week (I’m on vacation so no definite promise) will hopefully
contain less typos.

— Roland