Re: [OAUTH-WG] Dynamic Client Registration in trusted federation
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 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" > 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
Re: [OAUTH-WG] Dynamic Client Registration in trusted federation
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" 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
Re: [OAUTH-WG] Dynamic Client Registration in trusted federation
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" 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
Re: [OAUTH-WG] Dynamic Client Registration in trusted federation
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
