Hi Matt To add to George's point I think software statements solve your issue. For an example of how they are being used by UK OpenBanking please look here: https://bitbucket.org/openid/obuk/src/4630771db004da59992fb201641f5c4ff2c881f1/uk-openbanking-registration-profile.md?at=master&fileviewer=file-view-default
Dave On 1 June 2018 at 17:21, George Fletcher <gffletch=40aol....@dmarc.ietf.org> wrote: > Hi Matt, > > I think your use case is fully within the use cases enabled by > software-statements. > > A per client software-statement allows you to tighten the security model > (if desired). For example binding the software-statement to the client > presenting it in such a way as to have a cryptographic trust chain. > Unfortunately, the specifications are not clear about the best way to do > this. The Client Registration Request does allow for "extension parameters" > so that may be a way to add what's necessary. > > Thanks, > George > > On 6/1/18 10:33 AM, Matt Pryor - UKRI STFC wrote: > > Hi George, > > That did occur to me. It seemed like a bit of an abuse of the > software-statement system, but maybe it is partially intended for this. > > It still needs us to securely distribute the software statement as well. > Would you envisage a single software-statement for all installations, with > each installation specifying their own client-specific metadata, or would you > issue a software-statement per installation. The second sounds like it would > allow us to exert more control. > > Thanks for your help! > Matt > > On 01/06/2018, 15:28, "George Fletcher" <gffle...@aol.com> > <gffle...@aol.com> wrote: > > Given that you have a federation, could not the federation issue the > signed software-statement to each of the relying parties (existing or > old) and the AS will trust the dynamic client registration if and only > if the signed software-statement is signed by the federation. This fits > more closely with the trust framework model. > > Thanks, > George > > On 6/1/18 9:57 AM, Matt Pryor - UKRI STFC wrote: > > Hi, > > > > I am working on a use case of OAuth 2.0 in a federation and am after > some advice about bootstrapping trust. > > > > Each site in the federation has an OAuth 2.0 authorization server and > an OAuth 2.0 relying party. The relying party at each site needs to be > registered with all the authorization servers in the federation. We want to > automate as much of this process as possible, but restrict client > registration to trusted members of the federation. We also want to make > onboarding a new federation member as easy as possible. > > > > This seems an ideal use case for the Dynamic Client Registration > Protocol (RFC 7591). The RFC permits the client registration endpoint to > require a pre-existing token in order to register a new client which gives us > our security (only trusted federation members can register a client). > > > > The challenge seems to be in bootstrapping the initial trust. It seems > cumbersome to require that a new federation member must manually obtain a > token from each authorization server before registering - they may as well > manually register their client. I'd be interested to know if anyone has any > ideas for a solution other than securely distributing a shared secret to new > federation members. > > > > One possible option is to piggy-back on the legacy authn/z we already > have - users can obtain an X509 certificate from their home idp, which is > then trusted by all the other sites. We can then obtain SAML assertions about > their permissions based on that certificate. We could use this mechanism to > maintain a list of trusted admins, requiring authentication with an X509 > certificate with the correct SAML assertion for the client registration > endpoint. However, we are hoping to retire the X509 support in the > short-to-medium term, so I'm also looking for solutions that do not use it. > I'm also not sure how the use of X509 certificates would fit in with an > RFC-compliant implementation of the Dynamic Client Registration Protocol. > > > > Thanks in advance for your help, > > Matt > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- Dave Tonge
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
