ibops protocol version 1.0 - oasis | advancing open ... · web viewidentity based open exchange...

Identity Based Open Exchange Protocol Specification (IBOPS) 1.0

Working Draft 03

11 December 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-wd03 Working Draft 03 11 December 2015Standards Track Draft Copyright © OASIS Open 2015. 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......................................................................................................................................... 4

1.1 IBOPS............................................................................................................................................... 41.2 Terminology....................................................................................................................................... 41.3 Normative References....................................................................................................................... 41.4 Non-Normative References...............................................................................................................4

2 Overview............................................................................................................................................. 52.1 Identity............................................................................................................................................... 52.2 Authentication and Assurance...........................................................................................................52.3 Goals................................................................................................................................................. 62.4 Non-goals.......................................................................................................................................... 6

3 IBOPS................................................................................................................................................. 73.1 Overview........................................................................................................................................... 73.2 Scenario............................................................................................................................................ 73.3 User Enrollment................................................................................................................................. 73.4........................................................................................................................................................... 8

3.4.1 Certificate issuance.................................................................................................................... 83.4.2 Device registration..................................................................................................................... 8

3.5 Authentication.................................................................................................................................... 93.5.1 Overview.................................................................................................................................... 93.5.2 Client Software Authentication.................................................................................................103.5.3 User authentication..................................................................................................................103.5.4 Server Authentication...............................................................................................................10

3.6 Authentication Session Management..............................................................................................113.7 Authorization................................................................................................................................... 11

4 Best practices and Security Considerations......................................................................................124.1 Intrusion Detection........................................................................................................................... 12

4.1.1 Overview.................................................................................................................................. 124.1.2 Replay Prevention.................................................................................................................... 12

4.2 Standards, Audit, and Quality Control.............................................................................................124.2.1 Standards................................................................................................................................. 124.2.2 Audit Capabilities.....................................................................................................................12

4.3 Data Protection................................................................................................................................ 134.3.1 Network Transmissions............................................................................................................134.3.2 Data Protection Strategy..........................................................................................................134.3.3 Client-side data........................................................................................................................134.3.4 Server-side data.......................................................................................................................144.3.5 IBOPS Server Data..................................................................................................................14

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

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

Appendix C. Revision History...............................................................................................................18


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, 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 some different 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. This is achieved by using one or more authentication mechanisms to reach a defined level of assurance that mitigates the threats determined by the risk assessment [X.1254]. Higher levels of assurance 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-agnostic using RESTful API’s and JSON. Define the technical details necessary to implement this IBOPS (e.g., protocols, messages, etc.) Work with existing IdM solutions and protocols (e.g., OAuth, OpenID Connect, SAML).

2.4 Non-goals User enrollment and proofing levels 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 Scenario1. Bob 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. Then they take his picture and give him his corporate access card.

2. Bob wants to access corporate services from his phone, so he downloads and installs the corporate access app. The first time he runs the app he enters his username and password to login. The app then prompts him to enter the code he just received via SMS. Lastly, he is prompted to record his fingerprints using the phone’s fingerprint reader. The corporate server then provisions Bob’s device according to his company’s IT policies. This includes setting some policies and device restrictions, as well as installing special certificates required for access to corporate services.

3. Bob is working from home and wants to access corporate services from the family 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 beeps and asks Bob to touch the fingerprint reader. The phone beeps again and, a moment later, Bob has access to the corporate services on his home computer.

The three steps above map to the following functions:1. User Enrollment2.

2.1. Certificate Management2.2. Device Registration

3.3.1. Authentication3.2. Authorization

3.3 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 a number of 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, enrolment at LoA4 requires an in-person meeting between the entity and the RA, as well as extensive identity proofing.[IBOPS-specific requirements]Human resources created and employee account for Bob, which included the automatic generation of a unique ID. When Bob went to the IT department, they linked his username and password to that ID and added the mobile number he gave them. The also attached his picture and information about the access card.


Figure 2: User enrollment

3.4

3.4.1 Certificate issuanceCertificates are an important part of the IBOPS process. For each client device registered, a certificate and an associated key pair are generated and represent the pairing of an ID and a particular device. This pairing will be referred to as a registered device. A device cannot be registered until the certificate has been deployed to the device. A certificate and key pair must also be generated and deployed to the authentication server. The format of a certificate may vary from implementation to implementation, and the specific processes used for creation, deployment, management, and revocation are out of scope for this document. In the scenario above, the certificates and keys were deployed to the device the first time Bob ran the corporate app.

3.4.2 Device registration1) User initiates registration request.2) User authentication or step-up authentication may be required.3) Device authenticates with the server using IBOPS certs4) Device generates device fingerprint5) Biometric enrollment:

a) Acquire biometric factor data through the device (for example, face, fingerprint, iris, etc.).b) Generate the biometric vector (hash).c) Store biometric vector on the client for user authentication.

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.ABBIE we need to consider the interface between the biometric device reader and the client device. How can we trust this device? How can we prevent replay?


Figure 3 Device Registration

3.5 Authentication

3.5.1 OverviewSuccessful authentication of a registered is required to allow access to requested resources. IBOPS has multiple points of authentication to enable that:

The client software is authenticated using embedded default certificates that are shared with the server within a standard TLS session handshake.

After device registration, users are authenticated using biometrics, matched locally on a mobile device, which unlocks the keys for the client certificates.

The registered device authenticates to the server using a client certificate, shared over a standard TLS session handshake. A client certificate cannot be submitted to a server until the certificate is decrypted with the key from the previous step.

Server authentication is also enabled using server certificates shared with the client during the TLS


Each of these authentication points is described in detail in the following sections.

3.5.2 Client Software Authentication[EDITOR’S NOTE: we need to explain that the client-side software is necessary for better security, but it is not required for compliance with the protocol]When installed, the client application comes pre-loaded with a default X.509 certificate that allows 2-way TLS-based authentication to be immediately enforced and active throughout the registration and authentication stages. This certificate permits the establishment of a TLS session with the registration service. After registration, this default certificate is replaced with the client certificate.

3.5.3 User authentication

3.5.3.1 User AuthenticationA 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.

3.5.3.2 Device authenticationIBOPS authenticates at two levels: within the underlying TLS session and within the server itself: 1. TLS-level authentication of the client device utilizes an X.509 certificate that was generated and signed during device registration and then provided to the client. We refer to this as the client certificate. To authenticate a device, the client software unlocks the client certificate and submits it to the server as a part of the TLS session2 handshake. In line with the TLS handshake protocol the client then allows the client certificate to be verified by the server via the TLS “Certificate Verify” message. The client certificate is unlocked (decrypted) using a password obtained after successful authentication.2. After verification of the client certificate, the server login module extracts the client certificate’s device identifier (the GUID), looks up the appropriate account and establishes an authenticated session. In some implementation, this process may perform additional checks such as certificate revocation, and roles associated with that ID.

3.5.4 Server AuthenticationServer authentication is achieved using the underlying TLS session. To meet the IBOPS requirements of two-way authentication between client and server, IBOPS requires TLS or TLS using client and server X.509 certificates.The IBOPS server certificate used for TLS sessions is verified (signed) by a third party certificate authority (CA) using their private key.The client can check the integrity of the IBOPS certificate by referring to the CA’s public key, included in a certificate in the distribution of most common browsers and operating systems. This verification is completed as part of the standard SSL/TLS session handshake.

3.6 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

1 If enabled. See Section XXX under Security considerations. 2 Because the TLS session is using a different client certificate to that used initially, the TLS session is established with a different URI endpoint.ibops-protocol-v1.0-wd03 Working Draft 03 11 December 2015Standards Track Draft Copyright © OASIS Open 2015. All Rights Reserved. Page of

David Turner, 2015-12-03,

Is this for intrusion detection.

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, the session ID was created when the QR code was displayed. This call is a session opportunity meaning that the system showing the QR Code may, after authentication, allow the establishment of a session. Alternatively, the session opportunity may timeout or not authenticate. In the case of successful user authentication and session opportunity, we have a 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).Within the IBOPS server, a persistent session is established specific to the account referenced via the client certificate. Sessions may take in any type data as 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. At some point in time, the session completes. At session completion, all information about the session is written to a history/audit. In the case of disallowing a device, user or account, the appropriate client certificates get revoked by removing the GUID from the IBOPS server. All future calls to the server will no longer result in successful communication.

3.7 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 Best practices and Security Considerations4.1 Intrusion Detection

4.1.1 OverviewThe IBOPS standard requires the implementation of intrusion detection capabilities. Depending on the specific 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 configurable consecutive times. On a typical IBOPS implementation this could be around 4. Blacklisting may be enacted for a fixed period of time 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) whether is a device is blacklisted or not. If the device is blacklisted, all communication ceases. Depending on 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.

4.1.2 Replay PreventionOne of the largest threats to network based systems is replay. 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 built into the communication 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 Boriken 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.

4.2 Standards, Audit, and Quality Control

4.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).


4.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.

4.3 Data Protection

4.3.1 Network TransmissionsAll network transmissions are required by the BOPS standard 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. Boriken servers (typically Apache Tomcat) are configured to use TLSv1.2.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 / application does not support TLSv1.2, then it may fallback to lower version.Exact TLS configuration depends upon the IBOPS-compliant server configuration3. Naturally, strong key generation and exchange algorithms are encouraged - similarly with encryption algorithms, in recognition of possible constraints such as compatibility or performance issues.

4.3.2 Data Protection StrategyThe general IBOPS standard philosophy 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.Also 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.

4.3.3 Client-side dataSensitive data stored on the client side includes: the user’s biometric vector4 (NOT the full biometric) the encrypted p12 file containing client certificate and private key (optional or implementation specific) encrypted5 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.

3 This is blank in the v4 doc4 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.5 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.ibops-protocol-v1.0-wd03 Working Draft 03 11 December 2015Standards Track Draft Copyright © OASIS Open 2015. All Rights Reserved. Page of

On Android the p12 is stored in the app shared preferences6:/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 that the possession of a biometric vector alone is not sufficient in order 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/replayed, a client certificate must also be present and liveness must succeed in order to impersonate a user. In addition, IBOPS has replay protection mechanisms built in (see the section titled Replay Prevention).

4.3.4 Server-side data

4.3.5 IBOPS Server DataSensitive data that may be stored within the Boriken 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 BOPS server during Genesis and/or session creation.Depending on the IBOPS product or solution, session creation may add sensitive data. For example, the withdrawal of money from an ATM will add the account and amount as sensitive data.Every session that is started and completed for and on behalf of a user or devices is also stored as an audit/history. This allows administrators or other privileged users to see usage patterns and other critical audit data.

6 http://developer.android.com/reference/android/content/SharedPreferences.htmlibops-protocol-v1.0-wd03 Working Draft 03 11 December 2015Standards Track Draft Copyright © OASIS Open 2015. All Rights Reserved. Page of

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

5 # 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


ibops protocol version 1.0 - oasis | advancing open ... · web viewidentity based open exchange...

Documents