Ibops protocol Version 0 Working Draft 2 9 March 2015 Technical Committee



Download 202.14 Kb.
Page1/9
Date31.07.2017
Size202.14 Kb.
  1   2   3   4   5   6   7   8   9
iBOPS Protocol Version 1.0

Working Draft 1.2

9 March 2015



Technical Committee:

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



Chairs:

Scott Streit (scott@scottstreit.com), Villanova University

Abbie Barbir (abbie.barbir@bankofamerica.com), Bank of America

Editors:

Kalim Sheikh (ksheikh@hoyoslabs.com), Hoyos Labs Corp.

Scott Streit (scott@scottstreit.com), Villanova University

Abbie Barbir (abbie.barbir@bankofamerica.com), Bank of America



Related work:

  • The REST architectural style was developed by W3C Technical Architecture Group (TAG) in parallel with HTTP 1.1, based on the existing design of HTTP 1.0.[5] The World Wide Web represents the largest implementation of a system conforming to the REST architectural style.

  • JCP 1.1 Final Release available as PDF (normative) and HTML (non normative). Corresponds to the 1.1 API. The 1.1 changelog describes the differences between 1.0 and 1.1.

  • JCP 1.0 Final Release available as PDF (normative) and HTML (non normative). Corresponds to 1.0 API.


Abstract:
Identity Biometric Open Protocol Standard (iBOPS) provides Identity Assertion, Role Gathering, Multi-Level Access Control, Assurance, and Auditing. The iBOPS includes software running on a client device (Android, iPhone, etc.), a trusted iBOPS Server, and an Intrusion Detection(IDS) system. The iBOPS allows pluggable components to replace existing components functionality accepting integration into current operating environments in a short period of time. The iBOPS provides continuous protection to the resources and assurance of the placement and viability of adjudication, and other key features. Accountability is the mechanism that proves a service level guarantee of security. The iBOPS allows the systems to meet security needs by using the API. The iBOPS need not know whether the underlying system is a Relational Database Management System (RDBMS) or a Search Engine. The iBOPS functionality offers a “point and cut” mechanism to add the appropriate security to the production systems as well as to the systems in development. The architecture is a language neutral allowing REST, JSON and Secure Socket Layers(SSL) to provide the communication interface. The architecture is built on the servlet specification, open secure socket layers, Java, JSON, REST and Apache Solr. Each and every tool adheres to the open standards allowing maximum interoperability.
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.doc

Permanent “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 2014. 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 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 Contents

1 Introduction

1.1 Terminology

1.2 Normative References

2 Overview

2.1 Scope

2.2 Purpose

2.3 Intended audience

3 Definitions, acronyms and abbreviations

3.1 Definitions

3.2 Acronyms and abbreviations

4 Security Considerations

4.1 Background

4.2 Identification Assertion

4.3 Role Gathering

4.4 Access Control

4.4.1 General

4.4.2 Discretionary Access Control

4.4.3 Mandatory Access Control

4.5 Audit and Assurance

4.5.1 Background

4.5.2 Audit

4.5.3 System Integrity

5 iBOPS Interoperability

6 iBOPS Overview, Applications, Registration, and Prevention of Replay

6.1 Overview

6.2 Application

6.3 Registration

6.3.1 Background

6.3.2 Developers and the iBOPS Service

6.3.3 The End User and the iBOPS Service

6.4 Prevention of Replay

6.4.1 The Format of all Requests

6.4.2 Subsequent API Calls

7 iBOPS API Overview

7.1 Identity Assertion API

7.1.1 Developer API_Key

7.1.2 Application Identification

8 API

8.1 Enterprise Concepts



8.2 Format of API Cells

8.3 Enrollment

8.3.1 Overview

8.3.2 Post-Enrollment Communication

8.3.3 Is the Device blacklisted?

8.4 API – Enrollment

8.5 API – QROpportunity

8.5.1 Overview

8.5.2 /QROpportunity

8.5.3 /enterprise/RegisterSession Opportunity

8.5.3.1 Input

8.5.3.2 Output

8.5.4 /enterprise/GetsessionStatus

8.5.4.1 Input

8.5.4.2 Output

8.5.5 /enterprise/RegisterSession

8.5.5.1 Input

8.5.5.2 Output

8.5.6 /enterprise/AuthenticationRepsonse

8.5.6.1 Input

8.5.6.2 Output

8.6 Role API

8.6.1 Overview

8.6.2 Dynamic image code session construction at a glance

8.7 Access Control API

8.8 Auditing

8.9 Administration

8.10 Reporting

9 Client Device Requirements

10 Server-side intrusion Detection System

10.1 API List Blacklist

10.2 API – Incident

11 Conformance

12 Acknowledgments

Appendix A. Revision History

Appendix B. Glossary




  1. Directory: committees -> download.php
    download.php -> Emergency Interoperability Consortium Membership Meeting
    download.php -> Technical Communicators, Get ready: Here comes Augmented Reality! Rhonda Truitt
    download.php -> Oasis set tc
    download.php -> Iepd analyze Requirements Use Cases for edxl situation reporting messages Draft Version 4
    download.php -> Technical Committee: oasis transformational Government Framework tc chair
    download.php -> Reliability of Messages Sent as Responses over an Underlying Request-response Protocol
    download.php -> Service Component Architecture sca-j common Annotations and apis Specification Version 1 Committee Draft 03 – Rev1 + Issue 127
    download.php -> Scenario Two – Hurricane Warning
    download.php -> Technical Committee: oasis augmented Reality in Information Products (arip) tc chairs
    download.php -> This is intended as a Non-Standards Track Work Product. [Type the document title]

    Download 202.14 Kb.

    Share with your friends:
  1   2   3   4   5   6   7   8   9




The database is protected by copyright ©ininet.org 2020
send message

    Main page