Financial Profile - Revision history

Tomjones: /* Solutions */

2018-11-26T15:47:08Z

Solutions

← Older revision		Revision as of 15:47, 26 November 2018
Line 24:		Line 24:
	* FSISAC		* FSISAC
	* ISO TC-68 has begun		* ISO TC-68 has begun
	* [https://consumerdatastandardsaustralia.github.io/infosec/#symbols-and-abbreviated-terms Australian standard]		* [https://consumerdatastandardsaustralia.github.io/infosec/#symbols-and-abbreviated-terms Australian standard] looks like FAPI, but may be more broadly targeted.

	==References==		==References==

Tomjones: /* Solutions */

2018-11-26T15:41:04Z

Solutions

← Older revision		Revision as of 15:41, 26 November 2018
Line 25:		Line 25:
	* ISO TC-68 has begun		* ISO TC-68 has begun
	* [https://consumerdatastandardsaustralia.github.io/infosec/#symbols-and-abbreviated-terms Australian standard]		* [https://consumerdatastandardsaustralia.github.io/infosec/#symbols-and-abbreviated-terms Australian standard]
	* FSISAC

	==References==		==References==

Tomjones: /* Solutions */

2018-11-26T15:40:42Z

Solutions

← Older revision		Revision as of 15:40, 26 November 2018
Line 24:		Line 24:
	* FSISAC		* FSISAC
	* ISO TC-68 has begun		* ISO TC-68 has begun
			* [https://consumerdatastandardsaustralia.github.io/infosec/#symbols-and-abbreviated-terms Australian standard]
			* FSISAC

	==References==		==References==

Tomjones: /* Context */

2018-10-27T05:02:44Z

Context

← Older revision		Revision as of 05:02, 27 October 2018
Line 6:		Line 6:
	*The most fully developed profiles are now in development in Europe, especially the [https://tcwiki.azurewebsites.net/index.php?title=Open_Banking UK Open Banking] effort. Those have been consulted in creating this profile.		*The most fully developed profiles are now in development in Europe, especially the [https://tcwiki.azurewebsites.net/index.php?title=Open_Banking UK Open Banking] effort. Those have been consulted in creating this profile.
	*Because of strong regulations in all jurisdictions for financial transaction, there will be some "Financial Authority" in each jurisdiction which will determine the appropriate [[Identifier]]s for Financial Institutions, and perhaps for customers as well.		*Because of strong regulations in all jurisdictions for financial transaction, there will be some "Financial Authority" in each jurisdiction which will determine the appropriate [[Identifier]]s for Financial Institutions, and perhaps for customers as well.
			*[https://insidecybersecurity.com/sites/insidecybersecurity.com/files/documents/2018/oct/cs2018_0451.pdf The FSSCC profile] of the NIST cyber-security framework should serve as both a source of security assurance as well as a paradigm of federated frameworks that we could use in our framework design.

	==Problems==		==Problems==

Tomjones: /* Solutions */

2018-10-11T01:04:51Z

Solutions

← Older revision		Revision as of 01:04, 11 October 2018
Line 19:		Line 19:

	==Solutions==		==Solutions==
	* PSD2 and the Berlin Group are creating standards for Euro currency countries.		* PSD2 and the [http://berlin-group.org Berlin Group] are creating standards for Euro currency countries.
	* [https://bitbucket.org/openid/obuk/src/master/ UK open banking effort] well along the way to establish criteria for exchanging financial information and instructions.		* [https://bitbucket.org/openid/obuk/src/master/ UK open banking effort] well along the way to establish criteria for exchanging financial information and instructions.
	* FSISAC		* FSISAC

Tomjones: /* Context */

2018-10-11T00:56:29Z

Context

← Older revision		Revision as of 00:56, 11 October 2018
Line 4:		Line 4:
	==Context==		==Context==
	*As a part of the creation of a set of [[Identity Ecosystem]]s this profile is targeted to apply to any transaction that puts a user's financial assets at risk.		*As a part of the creation of a set of [[Identity Ecosystem]]s this profile is targeted to apply to any transaction that puts a user's financial assets at risk.
	*The most fully developed profiles are now in development in Europe, especially the [https://tcwiki.azurewebsites.net/index.php?title=Open_Banking UK Open Banking] effort. Those have been consulted in creating this profile		*The most fully developed profiles are now in development in Europe, especially the [https://tcwiki.azurewebsites.net/index.php?title=Open_Banking UK Open Banking] effort. Those have been consulted in creating this profile.
			*Because of strong regulations in all jurisdictions for financial transaction, there will be some "Financial Authority" in each jurisdiction which will determine the appropriate [[Identifier]]s for Financial Institutions, and perhaps for customers as well.

	==Problems==		==Problems==

Tomjones: /* Problems */

2018-10-11T00:53:58Z

Problems

← Older revision		Revision as of 00:53, 11 October 2018
Line 12:		Line 12:
	*Providers in a Financial transactions (basically banks and payment initiators) need to be well-known to the Financial authority		*Providers in a Financial transactions (basically banks and payment initiators) need to be well-known to the Financial authority

	# Certificate Issuance and Verification -- Key to the authentication and identity characteristics of TLS is the issuance and verification of certificates. There are a number of different approaches that can be applied to financial APIs - each with a different trust model.		# Certificate Issuance and Verification from UK Open banking -- Key to the authentication and identity characteristics of TLS is the issuance and verification of certificates. There are a number of different approaches that can be applied to financial APIs - each with a different trust model.
	## Standard website certificates issued by globally trusted certificate authorities trusted by the browser source. These standard "domain validated" certificates provide no authoritative identity assurances themselves, but are often times sufficient when the client has other means of confirming the identity of the financial API provider. It is possible for a provider to obtain an "extended validation" certificate which does provide assurance of the corporate identity of the provider. In practice these provide little additional benefit as the client will still need to make a decision based on external criteria as to whether they trust the API provider. One downside with this approach is that it is harder to use client certificates from the same certificate authorities as few of them will issue such certificates~~. If a deployment requires the use of client certificates then it may be appropriate to consider using a different trust model~~.		## Standard website certificates issued by globally trusted certificate authorities trusted by the browser source. These standard "domain validated" certificates provide no authoritative identity assurances themselves, but are often times sufficient when the client has other means of confirming the identity of the financial API provider. It is possible for a provider to obtain an "extended validation" certificate which does provide assurance of the corporate identity of the provider. In practice these provide little additional benefit as the client will still need to make a decision based on external criteria as to whether they trust the API provider. One downside with this approach is that it is harder to use client certificates from the same certificate authorities as few of them will issue such certificates.
	## Regional trust frameworks, such as eIDAS in the EU -- The eIDAS family of legislation in the EU provides a trust framework with qualified trust service providers. These service providers can issue both server and client certificates and there are various standards to support additional metadata in such certificates, such as the regulatory status of the owner of the certificate. For region specific deployments this approach may be of merit. Moreover such certificates have a clear and strong legal status and in some cases are mandated to be used by law.		## Regional trust frameworks, such as eIDAS in the EU -- The eIDAS family of legislation in the EU provides a trust framework with qualified trust service providers. These service providers can issue both server and client certificates and there are various standards to support additional metadata in such certificates, such as the regulatory status of the owner of the certificate. For region specific deployments this approach may be of merit. Moreover such certificates have a clear and strong legal status and in some cases are mandated to be used by law.
	## Federation Operators -- Some ecosystems, particularly closed ecosystems, delegate the responsibility for issuing certificates to a federation operator. This entity will have the responsibility for verifying the identity of the participants according to rules specific to the federation. Each participant in the ecosystem will trust the federation operator and may well have a specific contract or terms of service in place with such an operator. Examples of this approach in the UK are the UK Open Banking Directory and the Origo Unipass system.		## Federation Operators -- Some ecosystems, particularly closed ecosystems, delegate the responsibility for issuing certificates to a federation operator. This entity will have the responsibility for verifying the identity of the participants according to rules specific to the federation. Each participant in the ecosystem will trust the federation operator and may well have a specific contract or terms of service in place with such an operator. Examples of this approach in the UK are the UK Open Banking Directory and the Origo Unipass system.

Tomjones: /* Solutions */

2018-10-11T00:51:18Z

Solutions

← Older revision		Revision as of 00:51, 11 October 2018
Line 18:		Line 18:

	==Solutions==		==Solutions==
	* PSD2 and the UK open banking effort ~~are~~ well ~~on their~~ way to establish criteria for exchanging financial information and ~~instructuions~~.		* PSD2 and the Berlin Group are creating standards for Euro currency countries.
			* [https://bitbucket.org/openid/obuk/src/master/ UK open banking effort] well along the way to establish criteria for exchanging financial information and instructions.
	* FSISAC		* FSISAC
	* ISO TC-68 has begun		* ISO TC-68 has begun

Tomjones: /* Problems */

2018-10-11T00:44:45Z

Problems

← Older revision		Revision as of 00:44, 11 October 2018
Line 13:		Line 13:

	# Certificate Issuance and Verification -- Key to the authentication and identity characteristics of TLS is the issuance and verification of certificates. There are a number of different approaches that can be applied to financial APIs - each with a different trust model.		# Certificate Issuance and Verification -- Key to the authentication and identity characteristics of TLS is the issuance and verification of certificates. There are a number of different approaches that can be applied to financial APIs - each with a different trust model.

	## Standard website certificates issued by globally trusted certificate authorities trusted by the browser source. These standard "domain validated" certificates provide no authoritative identity assurances themselves, but are often times sufficient when the client has other means of confirming the identity of the financial API provider. It is possible for a provider to obtain an "extended validation" certificate which does provide assurance of the corporate identity of the provider. In practice these provide little additional benefit as the client will still need to make a decision based on external criteria as to whether they trust the API provider. One downside with this approach is that it is harder to use client certificates from the same certificate authorities as few of them will issue such certificates. If a deployment requires the use of client certificates then it may be appropriate to consider using a different trust model.		## Standard website certificates issued by globally trusted certificate authorities trusted by the browser source. These standard "domain validated" certificates provide no authoritative identity assurances themselves, but are often times sufficient when the client has other means of confirming the identity of the financial API provider. It is possible for a provider to obtain an "extended validation" certificate which does provide assurance of the corporate identity of the provider. In practice these provide little additional benefit as the client will still need to make a decision based on external criteria as to whether they trust the API provider. One downside with this approach is that it is harder to use client certificates from the same certificate authorities as few of them will issue such certificates. If a deployment requires the use of client certificates then it may be appropriate to consider using a different trust model.

	## Regional trust frameworks, such as eIDAS in the EU -- The eIDAS family of legislation in the EU provides a trust framework with qualified trust service providers. These service providers can issue both server and client certificates and there are various standards to support additional metadata in such certificates, such as the regulatory status of the owner of the certificate. For region specific deployments this approach may be of merit. Moreover such certificates have a clear and strong legal status and in some cases are mandated to be used by law.		## Regional trust frameworks, such as eIDAS in the EU -- The eIDAS family of legislation in the EU provides a trust framework with qualified trust service providers. These service providers can issue both server and client certificates and there are various standards to support additional metadata in such certificates, such as the regulatory status of the owner of the certificate. For region specific deployments this approach may be of merit. Moreover such certificates have a clear and strong legal status and in some cases are mandated to be used by law.

	## Federation Operators -- Some ecosystems, particularly closed ecosystems, delegate the responsibility for issuing certificates to a federation operator. This entity will have the responsibility for verifying the identity of the participants according to rules specific to the federation. Each participant in the ecosystem will trust the federation operator and may well have a specific contract or terms of service in place with such an operator. Examples of this approach in the UK are the UK Open Banking Directory and the Origo Unipass system.		## Federation Operators -- Some ecosystems, particularly closed ecosystems, delegate the responsibility for issuing certificates to a federation operator. This entity will have the responsibility for verifying the identity of the participants according to rules specific to the federation. Each participant in the ecosystem will trust the federation operator and may well have a specific contract or terms of service in place with such an operator. Examples of this approach in the UK are the UK Open Banking Directory and the Origo Unipass system.

Tomjones: /* Problems */

2018-10-11T00:44:19Z

Problems

← Older revision		Revision as of 00:44, 11 October 2018
Line 9:		Line 9:
	*Each jurisdiction creates their own [[Identifier]] domain for financial services and for the users of financial services, many of which are legal persons, but not natural persons.		*Each jurisdiction creates their own [[Identifier]] domain for financial services and for the users of financial services, many of which are legal persons, but not natural persons.
	*In all cases that are known in 2018, a natural person is required to take responsibility for the financial institution (FI) or other money handling organization for regulatory reasons.		*In all cases that are known in 2018, a natural person is required to take responsibility for the financial institution (FI) or other money handling organization for regulatory reasons.
	*Customers (or account holders or subjects) in a financial transaction need to be identifiable to money laundering governmental agencies, for example [https://corpgov.law.harvard.edu/2016/02/07/fincen-know-your-customer-requirements/ Fincen in the US]. This "know your customer (KYC)" requirement puts special meaning on the validation of the subject, but that is normally the responsibility for the FI. If both the sender and the receiver of financial assets are FIs, then both are responsible to to know the customer. Some jurisdictions may place a burden on any recipient, and the Financial ~~agency~~ would need to recognize that requirement.		*Customers (or account holders or subjects) in a financial transaction need to be identifiable to money laundering governmental agencies, for example [https://corpgov.law.harvard.edu/2016/02/07/fincen-know-your-customer-requirements/ Fincen in the US]. This "know your customer (KYC)" requirement puts special meaning on the validation of the subject, but that is normally the responsibility for the FI. If both the sender and the receiver of financial assets are FIs, then both are responsible to to know the customer. Some jurisdictions may place a burden on any recipient, and the Financial authority would need to recognize that requirement.
			*Providers in a Financial transactions (basically banks and payment initiators) need to be well-known to the Financial authority

			# Certificate Issuance and Verification -- Key to the authentication and identity characteristics of TLS is the issuance and verification of certificates. There are a number of different approaches that can be applied to financial APIs - each with a different trust model.

			## Standard website certificates issued by globally trusted certificate authorities trusted by the browser source. These standard "domain validated" certificates provide no authoritative identity assurances themselves, but are often times sufficient when the client has other means of confirming the identity of the financial API provider. It is possible for a provider to obtain an "extended validation" certificate which does provide assurance of the corporate identity of the provider. In practice these provide little additional benefit as the client will still need to make a decision based on external criteria as to whether they trust the API provider. One downside with this approach is that it is harder to use client certificates from the same certificate authorities as few of them will issue such certificates. If a deployment requires the use of client certificates then it may be appropriate to consider using a different trust model.

			## Regional trust frameworks, such as eIDAS in the EU -- The eIDAS family of legislation in the EU provides a trust framework with qualified trust service providers. These service providers can issue both server and client certificates and there are various standards to support additional metadata in such certificates, such as the regulatory status of the owner of the certificate. For region specific deployments this approach may be of merit. Moreover such certificates have a clear and strong legal status and in some cases are mandated to be used by law.

			## Federation Operators -- Some ecosystems, particularly closed ecosystems, delegate the responsibility for issuing certificates to a federation operator. This entity will have the responsibility for verifying the identity of the participants according to rules specific to the federation. Each participant in the ecosystem will trust the federation operator and may well have a specific contract or terms of service in place with such an operator. Examples of this approach in the UK are the UK Open Banking Directory and the Origo Unipass system.

	==Solutions==		==Solutions==