I promised to send a UC to the list as input to the discussion around new
token formats.
---
Several large-scale deployments of public-key use a "bag-of-keys" model
for key management: you stick endpoint information together with public
keys for those endpoints in a signable container which is then signed with
a private key associated with some "trust provider" an distributed to all
entities/relying parties.
Examples include various trust status lists formats and things like SAML
metadata.
The latter case (SAML metadata) isn't necessarily tied to the SAML v2
_protocol_ but it is used for that. Large-scale SAML federations are often
setup to depend on distribution of signed SAML metadata.
Consider the case when a large number of relying parties of such a SAML
federation are also either OAUTH2 resource or authorization servers. Today
all of those OAUTH2 entities have to be provisioned with separate client
secrets that have no relationship to the trust infrastructure already in use
in the federation.
It is not uncommon for such federations to have 1000s and sometimes
10000s of entities making client secret management something of a
scalability issue.
Even with dynreg the problem of managing all of those client secrets
would still remain a *huge* (operational) security and scalability issue.
There is therefore a desire among communities that have such deployments
to be able to re-use the key-management already in place for OAUTH2.
Note that this example isn't tied to the SAML protocol at all.
Leif
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
