Leif, I've read this a couple of times and I think I'm getting lost in partial SAML vs. OAuth terminology. As a result, I thought you were saying:
1. It isn't practical to issue client credentials even with Dynamic Registration 2. You want to re-use key management already in place with OAuth2. These statements seem to be in conflict. Did you mean to say for number 2 that you want to re-use key management already in place for SAML? Phil @independentid www.independentid.com [email protected] On 2012-11-08, at 8:01 AM, Leif Johansson wrote: > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
