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

Reply via email to