ibops protocol version 1.0 - oasis€¦ · web viewibops-protocol-v1.0-wd04working draft ... in...

Identity Based Open Exchange Protocol Specification (IBOPS) 1.0

Working Draft 04

5 February 2015

Technical Committee:OASIS Identity Based Attestation and Open Exchange Protocol Specification (IBOPS) TC

Chairs:Scott Streit ([email protected]), Villanova UniversityAbbie Barbir ([email protected]), Bank of America

Editor:Kalim Sheikh ([email protected]), Hoyos Labs Corp.Andrew Hughes ([email protected])David Turner ([email protected])

Additional artifacts:This prose specification is one component of a Work Product that also includes: XML schemas: (list file names or directory name) Other parts (list titles and/or file names)

Related work:This specification replaces or supersedes: Specifications replaced by this specification (hyperlink, if available)This specification is related to: Related specifications (hyperlink, if available)

Declared XML namespaces: list namespaces declared within this specification

Abstract:Summary of the technical purpose of the document.

Status:This Working Draft (WD) has been produced by one or more TC Members; it has not yet been voted on by the TC or approved as a Committee Draft (Committee Specification Draft or a Committee Note Draft). The OASIS document Approval Process begins officially with a TC vote to approve a WD as a Committee Draft. A TC may approve a Working Draft, revise it, and re-approve it any number of times as a Committee Draft.

URI patterns:Initial publication URI:http://docs.oasis-open.org/ibops/ibops-protocol/v1.0/csd01/ibops-protocol-v1.0-csd01.docPermanent “Latest version” URI:http://docs.oasis-open.org/ibops/ibops-protocol/v1.0/ibops-protocol-v1.0.doc(Managed by OASIS TC Administration; please don’t modify.)

Copyright © OASIS Open 2015. All Rights Reserved.All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as

ibops-protocol-v1.0-wd04 Working Draft 03 5 February 2015Standards Track Draft Copyright © OASIS Open 2016. All Rights Reserved. Page of

https://www.oasis-open.org/policies-guidelines/ipr

https://www.oasis-open.org/policies-guidelines/tc-process#standApprovProcess

https://www.oasis-open.org/policies-guidelines/tc-process#committeeDraft

https://www.oasis-open.org/policies-guidelines/tc-process#dWorkingDraft

http://www.hoyoslabs.com/

http://www.bankofamerica.com/

mailto:[email protected]

http://www.villanova.edu/

mailto:[email protected]

https://www.oasis-open.org/committees/ibops/

needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Table of Contents1 Introduction......................................................................................................................................... 5

1.1 IBOPS............................................................................................................................................... 51.2 Terminology....................................................................................................................................... 51.3 Normative References....................................................................................................................... 51.4 Non-Normative References...............................................................................................................5

2 Overview............................................................................................................................................. 62.1 Identity............................................................................................................................................... 62.2 Authentication and Assurance...........................................................................................................62.3 Goals................................................................................................................................................. 72.4 Non-goals.......................................................................................................................................... 7

3 IBOPS................................................................................................................................................. 83.1 Overview........................................................................................................................................... 83.2 Scenario............................................................................................................................................ 83.3 Setup phase...................................................................................................................................... 8

3.3.1 User Enrollment......................................................................................................................... 83.3.2 Device provisioning.................................................................................................................... 9

3.4 Binding phase.................................................................................................................................... 93.4.1 Device registration..................................................................................................................... 9

3.5 Authentication.................................................................................................................................. 103.5.1 Overview.................................................................................................................................. 103.5.2 Client Software Authentication.................................................................................................103.5.3 User authentication..................................................................................................................113.5.4 Server Authentication...............................................................................................................11

3.6 Authentication Session Management..............................................................................................113.7 Authorization................................................................................................................................... 12

4 Best practices and Security Considerations......................................................................................134.1 Intrusion Detection........................................................................................................................... 13

4.1.1 Overview.................................................................................................................................. 134.1.2 Replay Prevention.................................................................................................................... 13

4.2 Standards, Audit, and Quality Control.............................................................................................134.2.1 Standards................................................................................................................................. 134.2.2 Audit Capabilities.....................................................................................................................13

4.3 Data Protection................................................................................................................................ 144.3.1 Network Transmissions............................................................................................................144.3.2 Data Protection Strategy..........................................................................................................144.3.3 Client-side data........................................................................................................................144.3.4 Server-side data.......................................................................................................................154.3.5 IBOPS Server Data..................................................................................................................15

5 # Conformance.................................................................................................................................. 16Appendix A. Acknowledgments............................................................................................................17Appendix B. Implementation Example.................................................................................................18

B.1 Subsidiary section........................................................................................................................... 18B.1.1 Sub-subsidiary section.............................................................................................................18


Appendix C. Revision History...............................................................................................................19


1 Introduction1.1 IBOPSIBOPS defines an authentication mechanism that uses a registered device with a biometric reader to enable a user to authenticate in a different context, such as accessing a service on another device. It can be used as a stand-alone authentication mechanism or combined with other authentication factors.

1.2 TerminologyThe key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].

1.3 Normative References[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP

14, RFC 2119, March 1997. http://www.ietf.org/rfc/rfc2119.txt.[Reference] [Full reference citation]

1.4 Non-Normative References[Reference] [Full reference citation]

NOTE: The proper format for citation of technical work produced by an OASIS TC (whether Standards Track or Non-Standards Track) is:

[Citation Label]Work Product title (italicized). Edited by Albert Alston, Bob Ballston, and Calvin Carlson. Approval date (DD Month YYYY). OASIS Stage Identifier and Revision Number (e.g., OASIS Committee Specification Draft 01). Principal URI (version-specific URI, e.g., with stage component: somespec-v1.0-csd01.html). Latest version: (latest version URI, without stage identifiers).For example:

[OpenDoc-1.2] Open Document Format for Office Applications (OpenDocument) Version 1.2. Edited by Patrick Durusau and Michael Brauer. 19 January 2011. OASIS Committee Specification Draft 07. http://docs.oasis-open.org/office/v1.2/csd07/OpenDocument-v1.2-csd07.html. Latest version: http://docs.oasis-open.org/office/v1.2/OpenDocument-v1.2.html.


http://docs.oasis-open.org/office/v1.2/OpenDocument-v1.2.html

http://docs.oasis-open.org/office/v1.2/csd07/OpenDocument-v1.2-csd07.html

http://www.ietf.org/rfc/rfc2119.txt

2 Overview2.1 IdentityIn the physical world, the identity of a natural person is readily accepted and is based on an extensive set of characteristics or attributes. Some of these are physical features such as height, hair color, general appearance, mannerisms, behavior, etc. Others, like date of birth, place of birth, home address, and telephone number may also be used.In the online world, an identity is also made up of attributes. However, in this case, the identity may be limited to a single attribute or it may have many; it will depend on the context in which it appears. This applies to inanimate objects and other online services, as well as natural persons, so a user is often referred to as an entity.Identifiers and attributes can uniquely characterize an entity within a particular context. Because of this, an entity may have multiple identities including identities that can be subsets of another identity. There also may be intersections of identities. However, for various reasons (such as for privacy concerns), intersections of identities used for different purposes or in different contexts may be explicitly undesirable or even excluded.

2.2 Authentication and AssuranceMost communication processes require that the communication partners have adequate assurance or trust that they are communicating with the intended partner. Therefore, at the beginning of a communication, the partners try to reach a sufficient level of assurance using the identity information available to the partner, i.e., confidence in the binding between the entity and the presented identity. This process is called authentication and typically involves three or more participants:

Requester (e.g., user) - the entity whose identity is to be confirmed Identity provider (IdP) – the entity that confirms the identity of the requester Relying party (RP) – the entity that will rely on the confirmed identity

Figure 1 Typical Authentication Model

The information that can be used for identification of an entity is based on the entity's attributes. In practical terms, identification of an entity is usually based on a subset of its attributes since identification is limited by the context within which the entity exists and interacts. The narrower the context and the clearer the boundary conditions, the fewer the number of attributes necessary for identification.


The assurance level required should be based on a risk assessment of the transactions, services, or resource access for which an entity will be authenticated. Higher assurance can be achieved by using one or more authentication mechanisms to reach the necessary level of assurance to mitigate the threats determined by the risk assessment [X.1254]. This can be achieved by combining multiple factors that don’t share the same vulnerabilities.

2.3 Goals Describe the types of threat mitigated by IBOPS. Define an architecture that is language-neutral using RESTful API’s and JSON. Define the technical details necessary to implement IBOPS (e.g., protocols, messages, etc.) Show examples of integration with existing IdM solutions and protocols (e.g., OAuth, OpenID

Connect, SAML).

2.4 Non-goals User enrollment and proofing levels Device setup (e.g., software provisioning and credential management) Transaction session state as distinct from authentication session state Implementation-specific details (e.g., strength and type of encryption, deployment of client-side

software).


3 IBOPS 3.1 Overview

3.2 ScenarioBob has just been hired so he goes to the IT department to get a corporate account and his access card. Bob creates a username and password and gives his mobile phone number. They take his picture and give him his corporate access card. Because Bob wants to access corporate services from his phone, he downloads and installs the corporate access app. When Bob runs the app the first time, he is prompted to enter his username and password. The app then prompts him to enter the one-time code he just received via SMS. After a short wait, Bob is prompted to record his fingerprints using the phone’s fingerprint reader. Bob is working from home and wants to access corporate services from the home computer. He enters the URL for the corporate portal and enters just his username when prompted. A QR code appears on the screen with instructions for using the corporate app on his phone. Bob launches the app and points the phone’s camera at the QR code. The phone reads the code then asks Bob to touch the fingerprint reader. A moment later, Bob has access to the corporate services on his home computer.

The scenario above describes three distinct phases: Setup phase

o User enrollmento Device provisioning

Binding phaseo Device Registration

Use phaseo Authenticationo Authorization

3.3 Setup phase

3.3.1 User Enrollment[EDITOR’S NOTE: This text was copied directly from X.1254]The enrollment phase consists of four processes: application and initiation, identity proofing, identity verification, and record-keeping/recording. These processes may be conducted entirely by a single organization, or they may consist of a variety of relationships and capabilities provided by some organizations including shared or interacting components, systems and services.The required processes differ according to the rigor required by the applicable LoA. In the case of an entity enrolling under LoA1, these processes are minimal (e.g., an individual may click a "new user" button on a web page and create a username and password). In other cases, enrollment processes may be extensive. For example, enrollment at LoA4 requires an in-person meeting between the entity and the RA, as well as extensive identity proofing.Human resources created an employee file for Bob, which included the automatic generation of a unique identifier. When Bob went to the IT department, they linked his username and password to that identifier and added the mobile number he gave them. They also attached his picture and information on the access card.


Figure 2: User enrollment

3.3.2 Device provisioningA device must be properly provisioned before it can be registered and used for biometric authentication. This will usually include the installation of IBOPS-enabled client-side software and any necessary certificates or other credential. In addition to installing the corporate access app, may enterprise systems will also provision a device according to the company’s IT policies at the same time. This may include setting device policies and restrictions, as well as installing special addition credentials required by other corporate services.The implementation details of this step are out-of-scope of this document. However, this document will define a set of IBOPS-specific setup requirements.

3.4 Binding phase

3.4.1 Device registrationThis phase is the fundamental configuration process for IBOPS. During this process, a user’s identity is bound to the device’s identity and secured by the user’s biometric data. Typical steps for device registration:1) The Setup Phase [3.3] is complete.2) Optional setup of an SSL channel using IBOPS-specific credentials. 3) The device generates a device fingerprint.4) The device sends the device fingerprint, user identity and other necessary information as an

encrypted package to the server. 5) The user must be authenticated before the server processes the request. The details of this process

will be implementation specific and should use multiple authentication factors. 6) The server processes the information and responds with an encrypted package including a new

IBOPS-specific identifier and related credentials. 7) The device runs the biometric enrollment (face, fingerprint, iris, etc.) and creates one or more

biometric vectors, which are saved to secure storage on the device. The vectors are used to secure the IBOPS credentials.

Depending upon the implementation, the registration process may include verification of an existing identity. This can happen in several stages, and the order in which this happens depends on the particular product or solution. It is vendor dependent whether the certificate is tied to the user’s identity, meaning


each identity has one and only one certificate, or alternately may use a separate certificate per device registration and each one will be tied to the single identity.

Figure 3 Device Registration

3.5 Use phase

3.5.1 AuthenticationSuccessful authentication of a registered device is required to allow access to requested resources. A user is authenticated by matching biometric vectors and passing liveness tests1. The user’s biometrics, single factor or multi-factor, are acquired through the device (for example, face, fingerprint, iris, etc.) Biometric vector(s) are extracted from the acquired biometrics. The vector(s) are matched against saved biometric vector(s) obtained during genesis and enrollment.After the client-side software validates the user via their biometrics, the biometrics authentication result is sent to the server regardless of the matching result.

1 If enabled. See Section XXX under Security considerations. ibops-protocol-v1.0-wd04 Working Draft 03 5 February 2015Standards Track Draft Copyright © OASIS Open 2016. All Rights Reserved. Page of

Figure 4 IBOPS Authentication

3.5.1.1 Authentication Session ManagementIBOPS requires authentication session management to maintain the state of an authentication transaction, in part because of the stateless nature of HTTP. This means that every call to an IBOPS server must have a session identifier so that the server can persist the current state. This session identifier enables session management for the duration of the authentication process. Sessions are tied to a particular user interacting with resources via the IBOPS server for a defined period. Each registered device has a unique client certificate, and that certificate contains a GUID that the server uses to identify the user. The identification of the user’s ID occurs by taking the GUID for the device and looking up the user for the device in the IBOPS server. A session can be initiated in different ways. In the scenario in Section 3.2, a session identifier was created and displayed using a QR code. In the case of successful user authentication, we have an authentication session. In many instances, the authentication session will be distinct from, and managed separately from, the transaction session (i.e., what the user is trying to do).An authentication session may include data represented as sets of name/value pairs. This may be geospatial data, variable transaction amounts, or any other data we wish to store throughout the duration of the session. In the case of geo-fencing, which is wanting to control the physical location of a session, we add in latitude and longitude. When a session is completed, information about the session may be written to a history or audit file. If a device, user, or account fails validation, the system may choose to revoke the appropriate client certificates, which will block all future authentication request.

3.5.2 AuthorizationThe result of a successful authentication is typically used as the basis for authorizing the user to perform a transaction, or to access a resource or service. The authorization may depend solely on the result of the IBOPS authentication, or in combination with other authentication factors or attributes.


4 IBOPS Messages[EDITOR’S NOTE: The following are based on an initial proposal and have not yet been reviewed by the members of the technical committee.]

4.1 Register deviceRegisterDevice Request {

name (string): Name of device,info (string, optional): Details information of the device,os (string): OS of the mobile device,IMEI (string): Identifier of mobile device (e.g. InternationalMobile Equipment Identity),pushRegId (string): Push Notification Registration Id from the specificprovider that mobile has,memberExternalId (string): Enteprise integration external identifier(e.g. 'wsj'),loginData (string): JSON with external system login information. Itshall be used to authenticate against the external system in order tovalidated the account,deviceFingerprint (string): Device Fingeprint(SHA1 sum),val1 (string),val2 (string)

}Response {

clientCertificate (string): Base64 encoded p12 client certificate,clientCertificatePassword (string): Client Certificate Password,id (string): Internal Id of a new registered user profile,loginData (string): Encrypted JSON with profile data which shall besaved on mobile device,credentialsData (string): Encrypted JSON with credential filled in byuser,error (ErrorResponse, optional)}

ErrorResponse {errorCode (integer, optional),errorDescription (string, optional)

}}

4.2 AuthenticationIBOPSAuthenticate Request {

sessionId (string): identity of session passed in with the authentication request,usedUserIdentityAssertionMethods (array[int], optional): Set of identity assertion methods used to authenticate the user,memberExternalId (string): External Identifier of enterprise integration (e.g. 'wsj'),authenticationMode (string): Authentication method - values from adaptor authenticationModes (e.g. QR/NFC ...),


BiometricAuthenticationResult (string): Result of the client side authentication (biometrics). AUTHENTICATED, FAILED, CANCELED,loginData (string, optional): JSON with external system login information used to authenticate against the external system in order to validated the account,extraValues (string): Session Extra Values

}

Response {remoteServerResponse (string, optional): Server response,mandatoryUserIdentityAssertionMethods (array[int],optional): In case of ERR=158, this will be populatedwith the requested set of identity assertion methods,error (ErrorResponse, optional)

}ErrorResponse {

errorDescription (string, optional),errorCode (integer, optional)

}


5 Best practices and Security Considerations[EDITOR’S NOTE: This section still needs to be updated to match the changes in Section 3]

5.1 Intrusion Detection

5.1.1 OverviewThe IBOPS standard requires the implementation of intrusion detection capabilities. Depending on the particular implementation, these capabilities may provide active monitoring and blacklisting functionality to help address attacks, including credential spoofing via certificate impersonation, session replay, detection and prevention of account brute-forcing, session creation failures, and/or the detection of denial-of-service (distributed or single DOS) attacks. These functions should be governed by one or more intrusion detection systems which can take appropriate actions such as terminating session creation or blacklisting devices and/or IP addresses.The IBOPS standard also requires specific intrusion detection capabilities implemented within a system on both server and client sides. Client-side intrusion detection must be capable of identifying patterns of trial and error in order to blacklist itself, or if the user fails to authenticate more than a predefined number of consecutive attempts. On a typical IBOPS implementation this could be around 4. Blacklisting may be enacted for a fixed period or indefinitely until the device can be properly assured that it is safe and valid. The IBOPS server can query the Intrusion Detection System (IDS) to determine if a device is blacklisted or not. If the device is blacklisted, all communication ceases. Depending on the implementation, blacklisting may occur at the device level, the IP address level, the subnet level or beyond. A typical implementation may only blacklist on Device ID.The following outlines an intrusion detection function for IBOPS.

5.1.2 Replay PreventionOne of the largest threats to network-based systems is replay attacks. Consider the scenario of an attacker modifying target software on a device and/or stealing session information from a valid session for replay, in an attempt to gain unauthorized access to a server.Replay mitigation uses replay check values that are included in the messages to help prevent this type of attack.From the server side perspective, the server has to recognize that the replay check values are not correct when under attack so the device can be blacklisted. The replay check values are requested by the client during Genesis and are one way encrypted by the IBOPS Server. The server looks up the one-way encryption to find the values used for replay mitigation. Subsequent client calls use the check values placed by the client and expected by the server. If the values are as expected, communication continues. If the replay values are not expected the IDS receives a notification. Enough notifications and the client is blacklisted.

5.2 Standards, Audit, and Quality Control

5.2.1 StandardsIBOPS is designed to meet several minimum standards, including assessment against the Trusted Computer System Evaluation Criteria (TCSEC), which is a US Government Department of Defense (DoD) standard that sets basic requirements for assessing the effectiveness of computer security controls built into a computer system, the Director of the Central Intelligence Directive 6/3 protection levels 3, 4, and 5 (PL3, PL4, PL5), and the standards of Multiple Independent Levels of Security (MILS).


5.2.2 Audit CapabilitiesAuditing ensures the appropriate artifacts for continued verification and validation of trusted access. All administrative actions (modification via the Admin dashboard) and authentication actions are captured and stored in a data repository. Account-specific authentication records can be audited by a user with Administrator privileges, via an administrator dashboard.

5.3 Data Protection

5.3.1 Network TransmissionsAll network transmissions are required to run over Transport Layer Security (TLS) or its predecessor Secure Sockets Layer (SSL), with server and client-side X.509 certificates enforcing two-way authentication. Before a client and server can begin to exchange information protected by TLS, they must securely exchange keys and/or agree upon encryption keys and a cipher to use when encrypting data. These options are configurable and can also be negotiated on a per-session basis in line with client-side capabilities. For instance, if a client machine or application does not support TLSv1.2, then it may fallback to lower version.Exact TLS configuration depends upon the IBOPS-compliant server configuration. Naturally, strong key generation and exchange algorithms are encouraged - similarly with encryption algorithms, in recognition of possible constraints such as compatibility or performance issues.

5.3.2 Data Protection StrategyThe philosophy of the IBOPS standard is to prevent the centralized storage of sensitive data in one place. IBOPS does not create large server-side repositories of sensitive client data such as biometric images, for example.As a general rule encrypted data and the key to decrypt that data should not be in the same place. For example, in an IBOPS system, sensitive data such as the user’s website credentials are stored encrypted on the mobile device, with the associated key stored in the IBOPS server repository, attached to the user’s account. This helps prevent an attacker who has gained access to the mobile from reading the credentials, and vice-versa.

5.3.3 Client-side dataSensitive data stored on the client side includes: the user’s biometric vector2 (NOT the full biometric) the encrypted p12 file containing client certificate and private key (optional or implementation specific) encrypted3 user authentication data for third party identity

systemsOn IOS, all of this data is stored in the IOS KeyChain. This is an encrypted container that holds passwords for multiple applications and secure services.On Android the p12 is stored in the app shared preferences4:

2 The sensitivity of the biometric vector is debatable, as a full biometric can usually not be extracted from the vector and in the event the vector is stolen we help address replay via the intrusion detection capabilities plus presence of the Client Certificate.3 The user authentication data is stored in the same encrypted format that was returned from the Boriken server during genesis/enrolment. The data gets encrypted by the server using the Elliptic Curve Integrated Encryption Scheme (ECIES#) algorithm. The key used for this encryption (571 ECC) was generated and is stored on the server.4 http://developer.android.com/reference/android/content/SharedPreferences.htmlibops-protocol-v1.0-wd04 Working Draft 03 5 February 2015Standards Track Draft Copyright © OASIS Open 2016. All Rights Reserved. Page of

http://developer.android.com/reference/android/content/SharedPreferences.html

/data/data/com.your.package/shared_prefs/com.your.package_preferences.xmlThe biometric vector is stored internal to the client side application.It is important to note that except for a handful of unique situations, a full biometric data set cannot be derived from a biometric vector and the possession of a biometric vector alone is not sufficient to obtain authenticated access to the IBOPS server. Identity Assertion under the IBOPS standard relies on several stages of authentication, including biometric vector matching, liveness checking, and the submission of the client certificate. Should the biometric vector be replaced or replayed, a client certificate must also be present, and liveness must succeed to impersonate a user. Also, IBOPS has replay protection mechanisms built in (see the section titled Replay Prevention).

5.3.4 Server-side data

5.3.5 IBOPS Server DataSensitive data that may be stored on the server includes: Device identifiers Geospatial locations User identifiers such as email, phone number User roles client certificate password data Other possible attributes sent to the IBOPS server during device registration or an authentication

session.Depending on the IBOPS product or solution, session creation may add sensitive data. For example, following the withdrawal of money from an ATM the account number and the amount of the transaction will be stored as sensitive data.Every session that is started and completed for and on behalf of a user or devices may also be stored in a history or audit file. This allows administrators or other privileged users to see usage patterns and other critical audit data.


6 # ConformanceThe last numbered section in the specification must be the Conformance section. Conformance Statements/Clauses go here. [Remove # marker]


Appendix A. AcknowledgmentsThe following individuals have participated in the creation of this specification and are gratefully acknowledged:Participants:!!br0ken!!

[Participant Name, Affiliation | Individual Member][Participant Name, Affiliation | Individual Member]


Appendix B. Implementation Exampletext

B.1 Subsidiary sectiontext

B.1.1 Sub-subsidiary sectiontext


Appendix C. Revision History

Revision Date Editor Changes Made

WD03 2015/12/11 David Turner Major revisions to sections 1, 2, and 3

WD04 2016/02/05 David Turner Further work on section 3.

WD04b 2016/02/07 David Turner Added new section – IBOPS Messages


ibops protocol version 1.0 - oasis€¦ · web viewibops-protocol-v1.0-wd04working draft ... in...

Documents