--- a/latest/requirements/requirements_draft.txt Thu Jun 04 00:59:02 2015 -0400
+++ b/latest/requirements/requirements_draft.txt Thu Jun 04 14:59:41 2015 -0400
@@ -1,8 +1,18 @@
-Identity is the gate keeper but security is the door.
-
Erik Anderson
Bloomberg R&D & Co-chairman W3C Web Payments IG/SG
+Identity is the gate keeper but security is the door.
+- Security is the door
+- Identity is the lock
+- Credentials are the keys
+- Technology is the gatekeeper
+
+Also worded as
+- Encryption is the door
+- Identity is the lock
+- Credentials are the keys
+- Human metrics are the gatekeepers
+
Some requirement drafts for W3C Web Payments.
Even when technologies are developed inside the NSA, they don't remain exclusive for long. Today's top-secret programs become tomorrow's PhD theses and the next day's hacker tools. There exists quantum tools to sniff, regexp match, swap sip/sport/dip/dport/syn/ack, set ack and push flags, and add the payload to create the malicious reply. These tools, once top secret tools, are now open and available to all.
@@ -13,27 +23,39 @@
Requirements drafts.
Identity
- NOTE: We must move beyond static authentication and into the next generation of authenticating the identity of the user (or system)
- - Identity is ultimately a service of the account provider but the browser must facilitate features/capabilities to facilitate the binding of an electronic identity to the physical person if Web Payment API's are to be adopted throughout financial services.
+ NOTE: We must move beyond static authentication and into the next generation of authenticating the identity of the user
+ (or system)
+ - Identity is ultimately a service of the account provider but the browser must facilitate features/capabilities to
+ facilitate the binding of an electronic identity to the physical person if Web Payment API's are to be adopted
+ throughout financial services.
- Electronic identities must support attribute based configurable inputs
- - Electronic identities must not be identical across different account providers (ie email address, SSN, etc) but operate under a common framework.
+ - Electronic identities must not be identical across different account providers (ie email address, SSN, etc) but operate
+ under a common framework.
NOTE: For privacy concerns. Its possible for collisions to occur but these occurrences are unlikely
- An electronic identity must be unique per account provider and issued from the provider.
- NOTE: There exists conditions that an identity must be pseudo anonymous and unique per transaction but forensically linkable back to the user (if necessary by legal & regulatory processes
- NOTE: Out of scope for now - merit based electronic identities may not be issued from an account provider but solely from the end user.
+ NOTE: There exists conditions that an identity must be pseudo anonymous and unique per transaction but forensically
+ linkable back to the user (if necessary by legal & regulatory processes
+ NOTE: Out of scope for now - merit based electronic identities may not be issued from an account provider but solely
+ from the end user.
- Electronic identities must support attributes based on various selectable data elements of the user
NOTE: Below are system requirements. Depending on device capabilities these "must" requirements will not be achievable
- NOTE: If a device has limited capabilities and depending on legal+regulatory constraints not all transactional values will be capable on these low capability devices.
- NOTE: At the core an attribute is a tokenized form of any mandatory and discretionary inputs from both the account provider&holder. These can include but not limited to digitized documentation, tokenized biometric template matches, time elements, knowledge elements, location elements, or another token.
- - Attributes must have an ID associated with them for lookup purposes. These IDs/names shouldnt be overly descriptive to leak information.
- - Attributes must be capable of being derived from data elements based on digitized formats of a users analog documentation (credentials)
+ NOTE: If a device has limited capabilities and depending on legal+regulatory constraints not all transactional values
+ will be capable on these low capability devices.
+ NOTE: At the core an attribute is a tokenized form of any mandatory and discretionary inputs from both the account
+ provider&holder. These can include but not limited to digitized documentation, tokenized biometric template
+ matches, time elements, knowledge elements, location elements, or another token.
+ - Attributes must have an ID associated with them for lookup purposes. These IDs/names shouldnt be overly descriptive to
+ leak information.
+ - Attributes must be capable of being derived from data elements based on digitized formats of a users analog
+ documentation (credentials)
Example: Tokenized scan of a users drivers license.
- Attributes must be capable of being derived from and cryptographically linked to various biometric templates from a user
- Attributes must be capable of being derived from a secure cryptographic device in the possession of a user
- Attributes must be capable of being derived based on a users geolocation or a geofence of where a user should be.
NOTE: This is a must for high value transactions or any verifiable proximity based transactions.
- Attributes must be capable of being based on knowledge from a user. Such as a password, address, pin, pet name.
- - Attributes must be capable of being derived from random or pseudo-random data inputs (such as known information seeded to a random number generator)
+ - Attributes must be capable of being derived from random or pseudo-random data inputs (such as known information seeded
+ to a random number generator)
- Attributes should be capable of being derived from time based information. Example: Timelocks, Timebox
NOTE: Postdated check, 3 day hold on funds, etc
NOTE: Depending on the use case(s) this is essential but not in all cases.
@@ -43,16 +65,23 @@
- Attributes crypto materials must be stored in an encrypted container and unlockable by input from the intended user.
Example: Unlocked by a hardware token, static password, finger swipe, one time password, pin, etc.
- Biometric templates
- - Biometric templates should only be stored in a modified/secured format. Example: encrypted with a password or token in the users possession.
- - If plain fingerprint template matching is being used, the enrolment template must reside on a device/token owned by and only accessible under the knowledge of the user.
- - Account biometric templates must be enrolled with the account provider but protected against theft by some form of user input. Hardware token preferred.
+ - Biometric templates should only be stored in a modified/secured format. Example: encrypted with a password or token in
+ the users possession.
+ - If plain fingerprint template matching is being used, the enrolment template must reside on a device/token owned by and
+ only accessible under the knowledge of the user.
+ - Account biometric templates must be enrolled with the account provider but protected against theft by some form of user
+ input. Hardware token preferred.
NOTE: Unattended enrolment of biometrics is not advisable.
NOTE: Not all biometrics work with all users. Example: Finger scan metrics don't work on 5% of all individuals.
- - If identifier is for a machine attributes must be capable of being derived from virtual information such as IP address, MAC address, system ID, etc
+ - If identifier is for a machine attributes must be capable of being derived from virtual information such as IP address,
+ MAC address, system ID, etc
NOTE: Delegate authority to a system to issue reoccurring payments.
- - multiple inputs that go into the creation of an Electronic Identity must be cryptographically bound together so those elements of identity cannot be hijacked, separated and used for different intents i.e. No fishing
- - Identity hardening – Identity validation that grows with each trusted relationship that is linked to it…
- - To assure the users identity is confirmed the account provider must be able to request user provide a tier of factors/tokens to prove identity
+ - Multiple inputs that go into the creation of an Electronic Identity must be cryptographically bound together so those
+ elements of identity cannot be hijacked, separated and used for different intents i.e. No fishing.
+ NOTE: Non-repudiation is a must so a user should never be able to say "my private key was stolen so it wasnt me"
+ - Identity hardening – Identity validation that grows with each trusted relationship that is linked to it…
+ - To assure the users identity is confirmed the account provider must be able to request user provide a tier of
+ factors/tokens to prove identity
- Example: Alternate finger swipe
Biological data such as voice print, vein scan, palm print, retina scan, tissue sample.
Voice print
@@ -64,26 +93,31 @@
-
Authentication
- - As far as these requirements are written, Identity and Authentication can be used interchangeably because we are authenticating the
- identity of the user
+ - As far as these requirements are written, Identity and Authentication can be used interchangeably because we are
+ authenticating the identity of the user
Security
- We must move beyond static key cryptography and into the next generation of dynamic key management of cryptographic keys.
- Must support configurable identification
- Must utilize a standardized cryptographic messaging syntax like X9.73, RFC
- - Cryptographic key management must be done utilizing a standardized dynamic key management system based on a variety of attributes (such as X9.69)
+ - Cryptographic key management must be done utilizing a standardized dynamic key management system based on a variety of
+ attributes (such as X9.69)
- Attributes
- Attributes must have an ID associated with them for lookup purposes.
- Attributes must include descriptive names but these names should be secured to protect against information leakage.
- - Attributes must be capable of being derived from random or pseudo-random data (such as known information seeded to a random number generator)
+ - Attributes must be capable of being derived from random or pseudo-random data (such as known information seeded to a
+ random number generator)
- Attributes must be capable of being generated/input from a secure cryptographic device in the possession of a user
- Attributes must be capable of input data from the configurable identity outputs
- Each attribute must include permissions for read, write, or read&write access.
- Examples:
- - Attribute based on read only permissions. Example: Account provider can read a user initiated transaction but they never have permissions to initiate the transaction themselves
- - Attribute based on write only permissions. Example: used to write secure information for a regulatory body but only that particular regulatory body can read it.
+ - Attribute based on read only permissions. Example: Account provider can read a user initiated transaction but
+ they never have permissions to initiate the transaction themselves
+ - Attribute based on write only permissions. Example: used to write secure information for a regulatory body but
+ only that particular regulatory body can read it.
- Attribute based on bidirectional read and write permissions.
- Roles
- - Roles are independent of other roles. Thus a role should never include other roles, although 2 roles can include the same attributes.
+ - Roles are independent of other roles. Thus a role should never include other roles, although 2 roles can include
+ the same attributes.
- Roles must include descriptive names but these names should be secured to protect against information leakage.
- Examples of names:
- US Citizen
@@ -91,7 +125,8 @@
- Premium account holder of xyz bank
- Bloomberg employee.
- Attributes are assigned to roles. A role can include a variable number of attributes. Example: 1 to 10...0 attributes.
- - It is desirable that 1 attribute for each role be based on a maintenance value under control of the account provider. Account provider can rotate this attribute periodically or if it is believed a security compromise of the role has occurred.
+ - It is desirable that 1 attribute for each role be based on a maintenance value under control of the account provider.
+ Account provider can rotate this attribute periodically or if it is believed a security compromise of the role has occurred.
- Tokens
- Dynamic key management tokens are assigned to users.
- Tokens are the specialized container for roles & attributes.
@@ -101,54 +136,79 @@
- Cryptographic keys must include 1 random or pseudo-random input to their construction.
- Cryptographic keys are one time use only
- Keys and their input materials must be flushed from memory immediately after use
- - Security must not be centralized by 1 authority. Security must be configurable per account provider. Account provider can delegate to 3rd party if necessary.
- - Compromise of security of 1 account provider should not lead to information disclosure for all users of that providers service.
+ - Security must not be centralized by 1 authority. Security must be configurable per account provider. Account provider
+ can delegate to 3rd party if necessary.
+ - Compromise of security of 1 account provider should not lead to information disclosure for all users of that providers
+ service.
- Transactional messages, in and of themselves, a self-contained cryptographic object
- Cryptographic objects:
- Each cryptographic object supports tiers/layers of security
- - Cryptographic objects can contain another cryptographic object, arrray of said objects, trees of said objects, etc. Best analogy of this is an onion inside of onion.
- - Cryptographic objects are wrapped by a standardized descriptive layer such as X9.73, etc that allows metadata about the object(s) contents to be exposed without decrypting the object and unnecessarily exposing the contents as the object is routed/relayed through n-number of secure/unsecure networks.
+ - Cryptographic objects can contain another cryptographic object, array of said objects, trees of said objects, etc.
+ Best analogy of this is an onion inside of onion.
+ - Cryptographic objects are wrapped by a standardized descriptive layer such as X9.73, etc that allows metadata about
+ the object(s) contents to be exposed without decrypting the object and unnecessarily exposing the contents as the
+ object is routed/relayed through n-number of secure/unsecure networks.
- Example: Object/message routing/relaying should be possible without requiring each node to decrypt the object.
- Cryptographic objects are not tied to 1 cryptographic algorithm. Can be constructed by n-number of algorithms.
- - Which algorithms used to construct the object(s) in chosen by the account provider. There is no one international standard encryption algorithm so various algorithms must be available and choices provided.
- - Legal/regulatory information can be included for regulatory bodies without compromising the integrity of the message itself or enabling regulatory fishing.
- - There are many tiers of regulators so each regulatory layer must be its own security layer and constructed from its own set of attributes/dynamic keys
+ - Which algorithms used to construct the object(s) in chosen by the account provider. There is no one international
+ standard encryption algorithm so various algorithms must be available and choices provided.
+ - Legal/regulatory information can be included for regulatory bodies without compromising the integrity of the message
+ itself or enabling regulatory fishing.
+ - There are many tiers of regulators so each regulatory layer must be its own security layer and constructed from its
+ own set of attributes/dynamic keys
- If regulatory information is to be included in a transactional message the user must be made aware
- Encryption objects should be agnostic of the internal protected data and able to contain any arbitrary data/layload
- Cryptographic objects must be able to support encryption keys that unlock encryption keys.
- Example:
- - Each party be they user(s), financial, legal, or regulatory, can use their individual one time dynamic key to encrypt a randomly generated encryption key without having to duplicate and encrypt the object payload/data separately for each required party.
+ - Each party be they user(s), financial, legal, or regulatory, can use their individual one time dynamic key to
+ encrypt a randomly generated encryption key without having to duplicate and encrypt the object payload/data separately for each required party.
- Dynamic key thats used to protect a static private bitcoin key.
- At least 1 of the n-attribute inputs to the dynamic key management system must be exclusively under control of the user.
- - No 2 users of an account provider share the same set of attributes. Thus every message is uniquely secured for the end user. BAD WORDING. WHAT ABOUT GROUP ACCOUNTS?
+ - No 2 users of an account provider share the same set of attributes. Thus every message is uniquely secured for the
+ end user. BAD WORDING. WHAT ABOUT GROUP ACCOUNTS?
- Each message contains at least 1 random element to ensure the contents are uniquely encrypted.
- - On a users device Attributes and Cryptographic material used as input to construct a dynamic key management system must be deployed to the user
- in an out of bands communication (ie not in the same session with the transaction)
- - On a users device Attributes and Cryptographic material used as input to construct a dynamic key management system must be stored in a secure method such as an offline
- token or online with a layer of security such as identity based encryption.
+ - On a users device Attributes and Cryptographic material used as input to construct a dynamic key management system must
+ be deployed to the user in an out of bands communication (ie not in the same session with the transaction)
+ - On a users device Attributes and Cryptographic material used as input to construct a dynamic key management system must
+ be stored in a secure method such as an offline token or online with a layer of security such as identity based
+ encryption.
- Wire message formats:
- NOTE: There are various messaging standards for financial services. ISO 20022 is by far one of the biggest but there are other formats.
- - Wire messages are all encapsulated inside of a cryptographic object thats provide protection regardless of man-in-the-middle or routing of objects through unsecure networks
+ NOTE: There are various messaging standards for financial services. ISO 20022 is by far one of the biggest but there
+ are other formats.
+ - Wire messages are all encapsulated inside of a cryptographic object thats provide protection regardless of
+ man-in-the-middle or routing of objects through unsecure networks
- Example:
- TOR network or plain text HTTP session.
- There must be a mechanism to convert from a web friendly structures to wire structures:
- - Example: Convert from a browser friendly JSON or JSON-LD data structure(s) to ISO 20022, FIX, or card specific structure such as ISO 8583
+ - Example: Convert from a browser friendly JSON or JSON-LD data structure(s) to ISO 20022, FIX, or card specific
+ structure such as ISO 8583
- Account provider must be able to specify which standardized message format they require.
Credentials
- NOTE: Credentials are critical inputs to the Identity solution. We must be able to trace the Electronic identities back to the very documentation that went into the creation of those Identities. Ultimately the protection of those credential and access to the content of those credentials must come from to whom those credentials refer to. For consumer protection reasons, if someone wants to access the credentials of Erik Anderson then ONLY Erik Anderson should be able to provide cryptographic authorization to access to those credentials.
+ NOTE: Credentials are critical inputs to the Identity solution. We must be able to trace the Electronic identities back
+ to the very documentation that went into the creation of those Identities. Ultimately the protection of those
+ credential and access to the content of those credentials must come from to whom those credentials refer to. For
+ consumer protection reasons, if someone wants to access the credentials of Erik Anderson then ONLY Erik Anderson
+ should be able to provide cryptographic authorization to access to those credentials.
***********************************
Legal, Regulatory, and Consumer Protection
- Personal Information
- - A good summary of legal directions the US is taking when it comes to protecting and enforcing access to users personal information can be found on. http://us.practicallaw.com/6-502-0467. Many trails lead into findlaw.com, americanbar.com, federal trade commission, state statutes.
- - In many US states, end users can now sue non-government account and information holders who's data has been breached resulting in the mis-use, abuse, identity theft.
+ - A good summary of legal directions the US is taking when it comes to protecting and enforcing access to users personal
+ information can be found on. http://us.practicallaw.com/6-502-0467. Many trails lead into findlaw.com, americanbar.com,
+ federal trade commission, state statutes.
+ - In many US states, end users can now sue non-government account and information holders who's data has been breached
+ resulting in the mis-use, abuse, identity theft.
- This includes hijacking of information that is relayed through 3rd party companies.
- - This includes "unauthorized access" of data even by a employee of those companies. Loss of a personal device containing protected classifications of information.
- - These states directly require encryption of data and trigger notification to the user if their personal information is accesses. Harsh consequences for unauthorized access, unauthorized acquisition, and data acquired under false pretences.
+ - This includes "unauthorized access" of data even by a employee of those companies. Loss of a personal device
+ containing protected classifications of information.
+ - These states directly require encryption of data and trigger notification to the user if their personal information
+ is accesses. Harsh consequences for unauthorized access, unauthorized acquisition, and data acquired under false
+ pretences.
- Next generation of Business Operating procedures
- - Several state have now redefined of "personal information" beyond the general definition. This new definition now includes:
+ - Several state have now redefined of "personal information" beyond the general definition. This new definition now
+ includes:
- finger prints & biometric data
- account numbers
- Personal security questions like maiden name, mothers name, pet name
@@ -184,26 +244,33 @@
- Processing by third parties
- What additional requirements apply where a third party processes the data on behalf of the data controller?
- Electronic communications
- - Under what conditions can data controllers store cookies or equivalent devices on the data subject's terminal equipment?
+ - Under what conditions can data controllers store cookies or equivalent devices on the data subject's terminal
+ equipment?
- International transfer of data
- What rules regulate the transfer of data outside your jurisdiction?
- - Are data transfer agreements contemplated or in use? Have any standard forms or precedents been approved by national authorities?
- - Is a data transfer agreement sufficient to legitimise transfer, or must additional requirements (such as the need to obtain consent) be satisfied?
+ - Are data transfer agreements contemplated or in use? Have any standard forms or precedents been approved by national
+ authorities?
+ - Is a data transfer agreement sufficient to legitimise transfer, or must additional requirements (such as the need
+ to obtain consent) be satisfied?
- Does the relevant national regulator need to approve the data transfer agreement?
- Enforcement and sanctions
- What are the enforcement powers of the national regulator?
- What are the sanctions and remedies for non-compliance with data protection laws?
-In essence, any piece of data is regulated somewhere and by someone. No single Identity, Payment, Transactional system that intends to use the public internet can possibly adhere to the requirements of this constantly changing legal/regulatory environment.
+In essence, any piece of data is regulated somewhere and by someone. No single Identity, Payment, Transactional system that
+intends to use the public internet can possibly adhere to the requirements of this constantly changing legal/regulatory environment.
We need closed loop solutions over an open loop network like the internet.
So, if this is an impossible task to undertake using an open network how can this be accomplished?
-Simply: encrypt all data all the time and provide role based access controls to the very data elements of every document. In essence a computer programmable regulatory & legal environment all enforced via cryptography.
-
-Burden for that regulation must fall on the data storage provider but they need a secure front end, the browser, to mitigate risk for unauthorized access of the data.
+Simply: encrypt all data all the time and provide role based access controls to the very data elements of every document.
+In essence a computer programmable regulatory & legal environment all enforced via cryptography.
-Its in my belief if we extend the existing browser to a "secure browser with role based access controls enforced via cryptography" we can lock the hackers out of our data even if they penetrate our networks.
+Burden for that regulation must fall on the data storage provider but they need a secure front end, the browser, to mitigate
+risk for unauthorized access of the data.
-The above requirements will let the worlds financial systems store their data on a publicly available cloud storage more securely than their own internal networks. Jennifer Lawrence will never fear her iCloud photos are stolen again.
+Its in my belief if we extend the existing browser to a "secure browser with role based access controls enforced via
+cryptography" we can lock the hackers out of our data even if they penetrate our networks.
+The above requirements will let the worlds financial systems store their data on a publicly available cloud storage more
+securely than their own internal networks. Jennifer Lawrence will never fear her iCloud photos are stolen again.