Contract Exchange Extension 1.0 - Draft 3

Abstract

This extension defines 1) an extensible Contract format, 2) protocol to exchange the Contract, 3)protocol to share personal information based on the Contract and 4)protocol to provide access log. The Proposer creates a signed Proposal which describes what personal information is wanted and send it to the Signatory specified the End User. The Signatory, upon agreeing to it, signs agreements and provides the Contract. The combination of the Proposal and Contract is the mutually signed and is potentially legally binding. This Contract needs to be stored by all bound parties for a given length of time, usually spanning over many years depending on jurisdictions.

As these document size may be large while the user agent capability may be limited (e.g., mobile phones), sending them via direct communication and passing only the small reference called "Artifact" through the user agents are advisable. Therefore, as the protocol, use of Artifact Binding is strongly recommended.

Table of Contents

1.  Terminology
    1.1.  Requirements Notation
    1.2.  Definitions and Conventions
    1.3.  Terms
2.  Overview
    2.1.  Propser and Clients
    2.2.  OpenID Artifaict Binding
    2.3.  Signatory and Contract Parts
    2.4.  OpenID Assertion and Contract Parts
    2.5.  Contract Identifier as Endpoint
    2.6.  Personal Information Request
    2.7.  Access Log
3.  Files
    3.1.  JSON and Token
    3.2.  Structures
    3.3.  Storage and Timestamping
4.  Protocal
    4.1.  Sending Proposal
    4.2.  Accepting Proposal
    4.3.  Receiving Contract
    4.4.  Notify Contract Status
    4.5.  Data Request
5.  Security Considerations
    5.1.  non-repudiation
    5.2.  Man-in-the-middle
    5.3.  Eavesdropping
    5.4.  Malicious Providers
    5.5.  Phishing Attack
    5.6.  Private Key Compromise
Appendix A.  Acknowledgements
6.  Normative References
§  Authors' Addresses

1.  Terminology

1.1.  Requirements Notation

The 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] (Bradner, B., “Key words for use in RFCs to Indicate Requirement Levels,” 1997.) .

1.2.  Definitions and Conventions

All OpenID 2.0 Artifact Binding messages that contain OpenID Contract Exchange (CX) JSON node MUST contain "type" member starts with the following URI.

http://openid.net/specs/cx/1.0/

Variety of sub class message contains fragments at the end of the type URI.

1.3.  Terms

In addition to the terminology used in OpenID Artifact Binding 1.0 (Protivity Government Services and Nomura Research Institute, “OpenID Artifact Binding 1.0,” September 2010.) [OPENID_AB], following terms are used.

• Party
  • Entity which is bound to a contract and one of Client , Server , Proposer and Signatory.
  • Party may be a web server or a smart device client.
• End User
  • Person who has privillege of controlling Personal Information. End User MUST be identified at OpenID Provider and MAY authorize Contract to be signed and valid.
• Personal Information
  • Data which is own by End User and can be accessed to permitted Party.
• Contract
  • Document to prove that Party can access Personal Information under stated condition.
• Client
  • Personal Information user. OpenID Artifact Binding 1.0 (Protivity Government Services and Nomura Research Institute, “OpenID Artifact Binding 1.0,” September 2010.) [OPENID_AB] Relying Party.
• Server
  • Personal Information keeper. Exposes the Personal Information endpoint. OpenID Artifact Binding 1.0 (Protivity Government Services and Nomura Research Institute, “OpenID Artifact Binding 1.0,” September 2010.) [OPENID_AB] Relying Party.
• Proposer
  • Contract process initiator. Orchestrates the process of data access authorization between Clients and Server with the help of Signatory. OpenID Artifact Binding 1.0 (Protivity Government Services and Nomura Research Institute, “OpenID Artifact Binding 1.0,” September 2010.) [OPENID_AB] Relying Party.
• Signatory
  • Contract signer in the charge of the End User. OpenID Artifact Binding 1.0 (Protivity Government Services and Nomura Research Institute, “OpenID Artifact Binding 1.0,” September 2010.) [OPENID_AB] Provider.
• Request
  • Document to describe what data is wanted by Client
• Proposal
  • Document to hold a couple of Request and delivered to Signatory by Proposer to start the CX process.
• Acceptance
  • Document to describe how the personal information can be accessed.
• Contract Part
  • Document which compose Contract and hold a couple of Acceptance and securely distributed to specific Party.
• Token
  • Signed JSON object which serialized into a formated string. Format is defined in JSON Simple Sign 1.0 (Protivity Government Services and Nomura Research Institute, “JSON Simple Sign ver.1 draft00,” September 2010.) [JSON_SIMPLE_SIGN_1_0].
• Service
  • Data or experience provided by Proposer to End User. Some Services consist of couple of End User's Personal Information which are provided by Server and used by Client. Parties MUST fulfill Contract to collaborate to provide Service.
• PPID
  • Stands for "Pairwise Pseudonymous Identifier" or "Private Personal Identifier". It is End User's identifier asserted by Signatory to each specific OpenID Relying party including Client, Server or Proposer.

2.  Overview

The contract exchange extension(CX) is OpenID extension identified by the URI "http://openid.net/srv/cx/1.0/#". The contract is the document to prove that all parties bound to that have rights and obligations on consuming and providing services between each other.

CX protocol is based on OpenID Artifact Binding 1.0 (Protivity Government Services and Nomura Research Institute, “OpenID Artifact Binding 1.0,” September 2010.) [OPENID_AB] and some JSON(Javascript Object Notation) (, “The application/json Media Type for JavaScript Object Notation (JSON),” .) [JSON] messages structure used in CX are defined to exchange non-repudiate message. When an End User starts consuming a CX-based service at a RP(Proposer), the RP compose a Proposal JSON which is compiled with OpenID Artifact Binding Request files defined by parties to be bound to the CX service and contract. The RP starts OpenID Artifact Binding session with the Proposal to the OP(Signatory) specified by the End User, the End User is authenticated at the OP and agrees to compose the CX Contract, and finally the OP provides the CX Contract in OpenID Artifact Binding assertion to the RP.

With sharing Contract in advance and presenting Contract identfier at specified endpoints, the RP and other Parties bound to the Contract can be authenticated and request data services.

The following is a squence of main flow of OpenID Contract Exchange.

2.1.  Propser and Clients

Proposer, as a OpenID Relying Party, provides service experience to End User who is asserted by OpenID OP and has a principal at the Proposer. Other OpenID Relying Parties, Clients, MAY teams with Proposer to provide those services. Proposer and Client MAY use Personal Information which End User manages at the other OpenID Relying Parties, Servers.

To use Personal Information, Proposer and Clients MUST provide Request file which describes what kind of Personal Information they want to use.

+-------------------------------+
| <Proposal>                    |
|                               |
|  reqs:                        |
|  +-------------------------+  |
|  | +---------------------+ |  |
|  | | <Request>(Client 1) | |  |
|  | +---------------------+ |  |
|  | | <Request>(Client 2) | |  |
|  | +---------------------+ |  |
|  | | <Request>(........) | |  |
|  | +---------------------+ |  |
|  | | <Request>(Client N) | |  |
|  | +---------------------+ |  |
|  | | <Request>(Proposer) | |  |
|  | +---------------------+ |  |
|  +-------------------------+  |
|                               |
+-------------------------------+

Because Proposer is just another Client when it want to use Personal Information, there is no difference in architecuture between Reqeust of Clients and Request of Proposer.

2.2.  OpenID Artifaict Binding

If End User want to use the service provided by Proposer, Proposer initiates an OpenID Artifact Binding session. Proposer compiles all Request from Clients and Proposer itself to Proposal and add it OpenID request as CX extension. OpenID Artifact Binding request is sent to Signatory which is an OpenID OP in CX term because it signs contract in charge of End User.

2.3.  Signatory and Contract Parts

If the End User agree to create Contract, Signatory provides Contract Part for each Proposer and Client. Contract Part includes Acceptance file in which End Users identifier and the endpoint of his/her Personal Information are stated. All Contract Parts share a single identifier, Contract Identifier, which ensure all parties are bound to a single Contract.

Here is a sample Contract Part to be provieded to Server N which is going to be requested Personal Information by several Clients.

+------------------------------------+
| <Contract Part>                    |
|                                    |
|  party_id :                        |
|    "URL of Server N"               |
|                                    |
|  contract_id :                     |
|    http://op.net/contract/4321435  |
|                                    |
|  acceptances:                      |
|  +----------------------------+    |
|  | +------------------------+ |    |
|  | | <Acceptance>           | |    |
|  | | (Client a - Server N)) | |    |
|  | +------------------------+ |    |
|  | | <Acceptance>           | |    |
|  | | (Client b - Server N)) | |    |
|  | +------------------------+ |    |
|  | | ............           | |    |
|  | +------------------------+ |    |
|  | | <Acceptance>           | |    |
|  | | (Client z - Server N)) | |    |
|  | +------------------------+ |    |
|  +----------------------------+    |
|                                    |
+------------------------------------+

Also here is a sample Contract Part to be provieded to Client A which is going to request Personal Information to several Servers.

+------------------------------------+
| <Contract Part>                    |
|                                    |
|  party_id :                        |
|    "URL of Client A"               |
|                                    |
|  contract_id :                     |
|    http://op.net/contract/4321435  |
|                                    |
|  acceptances:                      |
|  +----------------------------+    |
|  | +------------------------+ |    |
|  | | <Acceptance>           | |    |
|  | | (Client A - Server 1)) | |    |
|  | +------------------------+ |    |
|  | | <Acceptance>           | |    |
|  | | (Client A - Server 2)) | |    |
|  | +------------------------+ |    |
|  | | ............           | |    |
|  | +------------------------+ |    |
|  | | <Acceptance>           | |    |
|  | | (Client A - Server N)) | |    |
|  | +------------------------+ |    |
|  +----------------------------+    |
|                                    |
+------------------------------------+

All Clients, Proposer, Server and Signatory will have its own Contract Part. Acceptances are included only in requester parties or responder parties.

2.4.  OpenID Assertion and Contract Parts

Proposer MAY obtain its Contract Part which is included in OpenID Artifact Binding Assertion as an extension parameter. Proposer MAY notify Contract Identifier to Client in the other process.

2.5.  Contract Identifier as Endpoint

Because Contract Identifier is the endpoint of Contract Parts, any bound party MAY request its Contract Part to the endpoint. Contract Part MUST be encrypted in JSON Simple Encryption with the party's public key.

2.6.  Personal Information Request

Clients or Proposer MAY request Personal Information to the endpoint stated in Acceptance of its own Contract Part. Server MUST encrypt response in JSON Simple Encryption with the requester's public key.

2.7.  Access Log

Servers MUST provide access log bound to the Contract to at least Signatory. Signatory in turn MUST provide those log to End User in some way.

3.  Files

CX exchange Contract JSON by extending OpenID Artifact Binding 1.0 (Protivity Government Services and Nomura Research Institute, “OpenID Artifact Binding 1.0,” September 2010.) [OPENID_AB] protocol. JSON(Javascript Object Notation) (, “The application/json Media Type for JavaScript Object Notation (JSON),” .) [JSON] is the default document format, the extended JSON Simple Sign 1.0 (Protivity Government Services and Nomura Research Institute, “JSON Simple Sign ver.1 draft00,” September 2010.) [JSON_SIMPLE_SIGN_1_0] is used for digital signature and the extended JSON Simple Encryption 1.0 (Protivity Government Services and Nomura Research Institute, “JSON Simple Encryption ver.1 draft00,” September 2010.) [JSON_SIMPLE_ENC_1_0] is used for asymmetric encryption with public key infrastructure.

3.1.  JSON and Token

CX uses JSON format which is used in OpenID Artifact Binding 1.0 (Protivity Government Services and Nomura Research Institute, “OpenID Artifact Binding 1.0,” September 2010.) [OPENID_AB] Request file and assertion. All file used for CX MUST have "type" member in a JSON object( enclosed in open and close curly braces ) and the value of "type" MUST be URI and start with :

http://openid.net/specs/cx/1.0/

CX JSON object MAY optionally have "id" member for specifying any particular JSON object. "id" MUST be a URI uniquely allocated by the creating party.

So, a generic CX JSON object likes like the following

{
    "type" : "http://openid.net/specs/cx/1.0/",
    "id"   : "http://rp.net/432144395df"
}

3.1.1.  Extending CX JSON

Although any CX JSON object MUST have members specified for "type", any other member MAY be used if parties agree the meaning of it. Any CX JSON MAY has any other JSON object as a member in itself. If a member is a JSON object, "type" and "id" SHOULD be checked firstly and this should be done recursively.

3.1.2.  Signed JSON and Token

Some CX JSON object MUST be digitally signed to prove a particular JSON object's composer. JSON Simple Sign 1.0 (Protivity Government Services and Nomura Research Institute, “JSON Simple Sign ver.1 draft00,” September 2010.) [JSON_SIMPLE_SIGN_1_0] is the default format. Some CX JSON is enveloped by JSON Simple Sign 1.0 (Protivity Government Services and Nomura Research Institute, “JSON Simple Sign ver.1 draft00,” September 2010.) [JSON_SIMPLE_SIGN_1_0] . Signed CX JSON is formed in the "Web Token Serialization" defined in JSON Simple Sign 1.0 (Protivity Government Services and Nomura Research Institute, “JSON Simple Sign ver.1 draft00,” September 2010.) [JSON_SIMPLE_SIGN_1_0]. Following the sample of signed and tokenized CX JSON.

      6a82841eea9c17677083b2965bc4e51e0e8e22e208121ab69711b3e5918c6677.eyAndGVzdCc6J2RhdGEnfQ==

3.1.3.  Encrypted JSON

Some CX JSON object SHOULD be asymmetrically encrypted to ensure that only the recipient can read the JSON object. JSON Simple Encryption 1.0 (Protivity Government Services and Nomura Research Institute, “JSON Simple Encryption ver.1 draft00,” September 2010.) [JSON_SIMPLE_ENC_1_0] is the default format.

3.1.4.  OpenID Extention

As an extension of OpenID, CX JSON object must be included as "cx" member of OpenID JSON object. Beause CX JSON object on OpenID message MUST be signed, "cx" member is actually a token string.

{
    ... OpenID JSON object parameters ...
    "cx" : "crypto_segment.claim_segment",

}

3.2.  Structures

3.2.1.  Request

Request is a file to declare what Personal Information a Client wants. After Request is delivered to Signatory which End User specified, the contents of Request MUST be displayed to the End User to help him to agree the request and specify the endpoint from which his Personal Infromation is accessed from Client. In special case, Client MAY specify Server and endpoint for Personal Information it wants.

Request is a extended OpenID Artifact Binding 1.0 (Protivity Government Services and Nomura Research Institute, “OpenID Artifact Binding 1.0,” September 2010.) [OPENID_AB] Request file enveloped by JSON Simple Sign 1.0 (Protivity Government Services and Nomura Research Institute, “JSON Simple Sign ver.1 draft00,” September 2010.) [JSON_SIMPLE_SIGN_1_0]. Every party bound to Contract MUST prepare Request in signed token format. Request shouldfdsa be prepared in the course of the process described in "Advertising Service (Advertising Service)".

Following parameters are placed in a JSON object held by "payload" parameter of JSON Simple Sign 1.0 (Protivity Government Services and Nomura Research Institute, “JSON Simple Sign ver.1 draft00,” September 2010.) [JSON_SIMPLE_SIGN_1_0] JSON.

• type
  • string(URI)
  • http://openid.net/specs/cx/1.0/#request"
• id
  • optional,string(URI))
  • Identifier for the particular Request file
• client_id
  • string(URI)
  • Identifier for Client.
• server_id
  • optional,string(URI)
  • Identifier for Server.
  • This parameter MAY be specified only when Client wants End User to permit to use a particular service. In this case, Client has already known the service endpoint.
• payment_to
  • optional,string(any)
  • End User SHOULD be given "payment_to" from Client for every CX service request to the service endpoint of Contract.
• payment_from
  • optional,string(any)
  • End User SHOULD pay "payment_from" to Client for every CX service request of Contract.
• template
  • optional,string(any)
  • This describes what Client wants as Presonal Information. Also conditions or jurisdic statement SHOULD be stated or refered for utilizing End User's Personal Information. End User MAY read this text to agree to create Contract.
• template_type
  • optiona,string(Content-Type)
  • Type of text provided by "template". Default is "text/plain".
• endpoint
  • optional,string(URI)
  • URI from which data is provieded at Server. Specified only when Client want Personal Information from a specific Server.
• notify
  • optional,string(URI)
  • Notifiation endpoint directely called by Party like Propose if Contract is provieded. Notification protocol described in "Notify Contract Status (Notify Contract Status)" section later.
• identity
  • optional,string
  • End user's OpenID identfier at Server. Mostly is not specified.
• client_certs
  • string(base64url)
  • Base64URL formatted string version of client_id's DER( defined in X.690 (INTERNATIONAL TELECOMMUNICATION UNION, “X.690 : Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER),” July 2002.) [X_690] ) encoded X.509 certificate used for this JSON Simple Sign 1.0 (Protivity Government Services and Nomura Research Institute, “JSON Simple Sign ver.1 draft00,” September 2010.) [JSON_SIMPLE_SIGN_1_0] JSON.
• server_certs
  • optional,string(base64url)
  • Base64URL formatted string version of server_id's DER( defined in X.690 (INTERNATIONAL TELECOMMUNICATION UNION, “X.690 : Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER),” July 2002.) [X_690] ) encoded X.509 certificate used when "server_id" specified in Request.

The following is a non-normative sample for CX Request JSON object:

{
    "type": "http://jsonenc.info/jss/",
     ....
    "payload": {
        "type" : "http://openid.net/specs/cx/1.0/#request",
        "client_id" : "http://rp.net",
        "server_id": "http://op.com",
        "payment_from" : "500JPY",
        "payment_to"     :  "5PT",
        "template" :
            "...(base64 encoded text for End User to grant the CX contract)..."
        "client_certs" : "...( Base64URL STRING OF client_id's DER ENCODED X.509 CERTIFICATE)...",
        "server_certs" : "...( Base64URL STRING OF server_id's DER ENCODED X.509 CERTIFICATE )...",
        ... ( OTHER OPENID REQUEST PARAMTERS ) ...,
        ... ( OTHER JSON SIMPLE SIGN PARAMTERS ) ...
    }
}

3.2.2.  Proposal

Proposal is a contrainer JSON to hold Request Token of parties from all Client. Proposal itself MUST be a Token to be conveyed in OpenID Artifact Binding request file to Signatory.

Following parameters are placed in a JSON object held by "payload" parameter of JSON Simple Sign 1.0 (Protivity Government Services and Nomura Research Institute, “JSON Simple Sign ver.1 draft00,” September 2010.) [JSON_SIMPLE_SIGN_1_0] JSON.

• type
  • string(URI)
  • http://openid.net/specs/cx/1.0/#proposal
• id
  • string(URI)
  • unique identifier for a specific Proposal specified by Proposer
• proposer_id
  • string(URI)
  • Identifier for Proposer
• reqs
  • array of object( JSON Simple Sign 1.0 (Protivity Government Services and Nomura Research Institute, “JSON Simple Sign ver.1 draft00,” September 2010.) [JSON_SIMPLE_SIGN_1_0] )
  • JSON array of Requests Token.
• notify
  • optional,string(URI)
  • Signatory MAY directly send message to this URI. As described later in "Notify Contract Status (Notify Contract Status)" section later, Signatory MAY notify the status of Contract to Proposer.
• proposer_certs
  • string(base64url)
  • Base64URL formatted string version of Proposer's DER (defined in X.690 (INTERNATIONAL TELECOMMUNICATION UNION, “X.690 : Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER),” July 2002.) [X_690] ) encoded X.509 certificate used for this JSON Simple Sign 1.0 (Protivity Government Services and Nomura Research Institute, “JSON Simple Sign ver.1 draft00,” September 2010.) [JSON_SIMPLE_SIGN_1_0] envelope.

The following is a non-normative sample for Proposal JSON object:

{
    "type": "http://jsonenc.info/jss/",
     ....
    "payload": {
      "type": "http://openid.net/specs/cx/1.0/#proposal",
      "id" : "http://rp.net/432143214321",
      "proposer_id" : "http://rp.net/",
      "reqs": [
        "6a82841eea9c17677083b2965bc4e51e0e8e22e208121ab69711b3e5918c6677.eyAndGVzdCc6J2RhdGEnfQ==",
        "1cf28c36f7fbb9e97828a687706cd14458d4b81713264d12852a0c8a669bee78.eyAnc2FtcGxlJzondGhlIG90aGVyJ30=",
      ]
      "proposer_certs": "...( BASE64URL STRING OF PROPOSER's DER ENCODED X.509 CERTIFICATE )...",
      .... ( OTHER EXTENDED PROPOSAL JSON MEMBERS )...

    }
}

3.2.3.  Acceptance

Acceptance is a response file of original Request "payload" and describes what is End User's PPID, where End User's Personal Information comes from and any other data required to response End User's Personal Information by Server. Signatory MUST produce two Acceptances for a single Request, one is for Client's Contract Part and the other is for Server's Contract Part. Personal information like canonical identifier SHOULD be different from each other.

Other paramters than the following have same meaning as ones defined in Request.

• type
  • string(URI)
  • "http://openid.net/specs/cx/1.0/#acceptance"
• id
  • string(URI)
  • unique identifier given by Signatory
• request_id
  • string(URI)
  • Identifier to refer to original Request.

The following is a non-normative sample for Acceptance object:

{
    "type"              : "http://openid.net/specs/cx/1.0/#acceptance",
    "client_id"         : "http://rp.net",
    "server_id"         : "http://op.com",
    "payment_from"      : "500JPY",
    "payment_to"        :  "5PT",
    "template"          :
       " ... (base64 encoded text for End User to grant the CX contract)....",
    "request_id"        : "http://rp.net/proposal/i393",
    "endpoint"          : "http://op.com/endpoint/",
    "identity"          : "http://op.com/user/g3430",
    ...( OTHER OPENID REQUEST PARAMTERS ) ...,
}

3.2.4.  Contract Part

Contract Part is container JSON object of Acceptances and enveloped by JSON Simple Sign 1.0 (Protivity Government Services and Nomura Research Institute, “JSON Simple Sign ver.1 draft00,” September 2010.) [JSON_SIMPLE_SIGN_1_0]. Contract Part is a part of Contract and provided for each Party by Signatory. All Contract Part shares a Contract Indenfier.

Following parameters are placed in a JSON object held by "payload" parameter of JSON Simple Sign 1.0 (Protivity Government Services and Nomura Research Institute, “JSON Simple Sign ver.1 draft00,” September 2010.) [JSON_SIMPLE_SIGN_1_0] JSON.

• type
  • string(URI)
  • http://openid.net/specs/cx/1.0/#contract_part
• id
  • opitinal,string(URI)
  • Identifier to this Contract Part
• contract_id
  • string(URI)
  • Unique URL given by Signatory. All Contract Part provided to each Party for a Proposal MUST be same.
• party_id
  • string(URI)
  • client_id, server_id or proposer_id of this Contract.
• proposal_id
  • string(URI)
  • Identifier to original Proposal. The signature segment of the original Proposal Token MUST be appended to the end of the original Proposal URI as URI fragment.
• acceptances
  • array of object(Acceptance)
  • JSON array of Acceptance JSON object.
• signatory_certs
  • string(base64url)
  • Base64URL formatted string of Signatory's DER( defined in X.690 (INTERNATIONAL TELECOMMUNICATION UNION, “X.690 : Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER),” July 2002.) [X_690] ) encoded X.509 certificate used for this JSON Simple Sign 1.0 (Protivity Government Services and Nomura Research Institute, “JSON Simple Sign ver.1 draft00,” September 2010.) [JSON_SIMPLE_SIGN_1_0] JSON.

The following is a non-normative sample for Contract Part object:

{
    "type": "http://jsonenc.info/jss/",
     ....
    "payload": {
        "type"        : "http://openid.net/specs/cx/1.0/#contract",
        "id"          : "http://op.com/id/f43213214",
        "contract_id" : "http://op.com/id/contract/x43513514",
        "party_id"    : "http://res.net/",
        "acceptances" : [
                {
                    "type"      : "http://openid.net/specs/cx/1.0/#acceptance",
                    "id"        : "http://op.com/id/f43213215",
                    "client_id" : "http://rp1.net/",
                    "server_id" : "http://res.net/",
                    "endpoint"  : "http://res.net/endpoint/",
                    "identity"  : "http://op.com/user/x43432",
                        .....

                },
                {
                    "type"      : "http://openid.net/specs/cx/1.0/#acceptance",
                    "id"        : "http://op.com/id/f43213216",
                    "client_id" : "http://rp2.net/",
                    "server_id" : "http://res.net/",
                    "endpoint"  : "http://res.net/endpoint/",
                    "identity"  : "http://op.com/user/y43432",
                        .....
                }
            ],
            "signatory_certs"
                : ".... ( BASE64URL STRING OF SIGNATORY's DER ENCODED X.509 CERTIFICATE ) ...",

            ... ( OTHER JSON SIMPLE SIGN PARAMTERS ) ...
        }
    }
}

3.2.5.  Status

Status is a simple JSON object to describe the status of Contract.

• type
  • string(URI)
  • http://openid.net/specs/cx/1.0/#status
• proposal_id
  • optional,string(URI)
  • This identifier is an unique identifier referring Proposal which Contract is being created for.
• contract_id
  • string(URI)
  • This identifier is an unique identifier referring Contract.
• status
  • string
  • status description about proposal or contract.
  • One of the following : "contract_created","contract_discarded","contract_pending","contract_inquiring".

The following is a non-normative sample for Status object:

{
    "type" :  "http://openid.net/specs/cx/1.0/#status",
    "proposal_id" :  "http://rp.net/cx/54643",
    "contract_id" : "http://op.com/contract/f43213214",
    "status" : "pending" ,
     ...    (other  JSON MEMBERS )   ...
}

3.3.  Storage and Timestamping

The Contract is supposed to act as a proof of agreement in case of dispute at a later date. Since contracts may be long term documents, there is a risk that are not so relevant in transient processing, such as Algorithm Compromise. Thus, care should be taken to appropriately process the contract through Timestamping etc.

4.  Protocal

4.1.  Sending Proposal

4.1.1.  Advertising Service

Before advertising CX Service, Proposer MUST collect all Request token related to that Service. Some Request token MAY be provided by any party other than the Proposeritself.

Proposer SHOULD provide an user interface like image button for End Users to click to go to the Service and Proposer starts providing Proposal and CX process.

Also Signatory party MUST advertise it can be a OpenID CX Signatory OP. In the case of using XRDS, Type element MUST be http://openid.net/specs/cx/1.0/.

4.1.2.  Providing CX Proposal

When an End User visits the particular CX Service at the Proposer, the Proposer firstly composes a Proposal for the End User. All Request Token to be bound to the Contract MUST be included in "reqs" member of Proposal JSON object. Proposal JSON MUST be finally singed into a Proposal Token.

4.1.3.  Start OpenID Artifact Binding Session

A Proposal Token is a extension of OpenID Artifact Binding. It SHOULD be a member of Artifact Binding Request file JSON object like in the following sample JSON:

{
    ...( OPENID ARTIFACT BINDING  REQUEST FILE JSON MEMBERS ) ...,
    "cx" : "crypto_segment_of_cx_proposal_token.claim_segment_of_cx_proposal_token",
}

OpenID authentication request session MUST be started to the Signatory specified by the End User at the Proposer's CX Service page.

4.2.  Accepting Proposal

4.2.1.  Accepting OpenID Artifact Binding Request

When an End User request a OpenID Artifact Binding request or a Proposer directly sends Request Registration request, Signatory SHOULD check if that request includes extensions named "cx".

4.2.2.  Verify Proposal

If OpenID request file containes "cx" extension,the Proposal Token signature MUST be verified in the way described in JSON Simple Sign 1.0 (Protivity Government Services and Nomura Research Institute, “JSON Simple Sign ver.1 draft00,” September 2010.) [JSON_SIMPLE_SIGN_1_0].

All Reqeust Tokens in "reqs" array MUST be verified.

4.2.2.1.  Policy Based Contract

If End User configures his/her policy at Signatory to issued Contract for specific claims's condition, Signatory MAY issue Contract without authenticating End User. Signatory MAY return OpenID Assertion including CX Contract in such case.

4.2.3.  Grants from Authenticated End User

If Proposal and all Requests in it are valid, End User MUST be authenticated. Signatory MUST display "template" what exactly each Party requests to the authenticated End User. To compose a Contract, the End User MUST agree the content displayed by Signatory.

4.2.4.  Compose Acceptance for Each Request

If End User agrees, Signatory creates two Acceptance JSON objects for each Request, one for Client and the other for Server. Personal information parameter MAY be different from each other.

4.2.5.  Compose Contracts

Signatory provides Contract Part JSON objects for all Parties. Each Contract Part shares unique URI, Contract Identifier, as "contract_id" member of it. All Acceptance JSON objects are stored in "acceptances" array member of that JSON object.

The original Proposal MUST be refered as "proposal_id" with its identifier. The digest segment of the Proposal Token MUST be appended as URI fragment.

Signatory MUST publish Contract Part in exchange for "contract_id" and "party_id" from a Party in the form of Contract Token which is the product of JSON Simple Encryption 1.0 (Protivity Government Services and Nomura Research Institute, “JSON Simple Encryption ver.1 draft00,” September 2010.) [JSON_SIMPLE_ENC_1_0].

4.3.  Receiving Contract

4.3.1.  Responding a CX Contract in OpenID Assertion

If Proposer as RP request OpenID Artifact Binding assertion request and there is a Contract Part Token to be bound to that, the OP as Signatory MUST return it as a "cx" member of the assertion JSON object.

{
    ...( OPENID ARTIFACT BINDING  ASSERTION JSON MEMBERS ) ...,
    "cx" : "crypto_segment_of_cx_contract_part_token.claim_segment_of_cx_contract_part_token",
}

But if no Contract Part is available at the time when RP requests the assertion, OP MUST return Status JSON object as "cx" member of assertion JSON object.

{
    ...( OPENID ARTIFACT BINDING  ASSERTION JSON MEMBERS ) ...,
    "cx" : {
                "type" :   "http://openid.net/specs/cx/1.0/#status",
                 ... ( OTHER CX STATUS JSON MEMBERS ) ...
             }
}

4.3.2.  Verifying Contract

If the "cx" member of assertion JSON object is a Contract Part Token string , Proposer MUST verify the signature of JSON Simple Sign 1.0 (Protivity Government Services and Nomura Research Institute, “JSON Simple Sign ver.1 draft00,” September 2010.) [JSON_SIMPLE_SIGN_1_0] first. Proposer MUST store the Contract Part Token if it is valid JSON Simple Sign 1.0 (Protivity Government Services and Nomura Research Institute, “JSON Simple Sign ver.1 draft00,” September 2010.) [JSON_SIMPLE_SIGN_1_0].

Proposer SHOULD explain to the End User that a Contract has been successfully created and now Proposer or Cleints is ready to request data according to the Contract.

If the "cx" member is a Status JSON object, Proposer SHOULD explain to the End User that a Contract has not been created yet at Signagory and the reason by "status" member of Status JSON object. Signatory MAY be notified later that the Contract is created by the Signatory.

4.4.  Notify Contract Status

Signatory and other Party MAY send the status of Contract to the endpoint specified by "notify" member of Proposal or Request. "status" query parameter MUST be a Status JSON object.

Signatory and Party MAY request their Contract Party Token using Data Request mechanism.

4.5.  Data Request

4.5.1.  CX Data Request

4.5.1.1.  Endpoint

Client MAY request data from a endpoint exposed by Server bound to the same Contract. The endpoint of End User's Personal Information is specified "endpoint" parameter of Request and Acceptance JSON.

Access log records MAY be requested in the same endpoint when "log" parameter is set to "true".

Also Party MAY request its Contract Part Token dicrectly to Signagory. The endpoint URL for Contract Part Token is "contract_id" itself.

4.5.1.2.  Parameters

CX data request parameters to be sent to URI described "Endpoint" section are definend in the following.

• party_id
  • REQUIRED Value: An identfier of Party. Server MUST encrypt Personal Information with the public key of Client in the way defined in JSON Simple Encryption 1.0 (Protivity Government Services and Nomura Research Institute, “JSON Simple Encryption ver.1 draft00,” September 2010.) [JSON_SIMPLE_ENC_1_0] .
• contract_id
  • REQUIRED. Value: Contract identfier.
• log
  • Optional. If this is set "true", access log records MUST be returned.
• from
  • Optional. This is the "from date" of access log records to be returned.
• to
  • Optional. This is the "to date" of access log records to be returned.

4.5.1.3.  Encrypted Response

Data response MUST be formed in JSON Simple Encryption 1.0 (Protivity Government Services and Nomura Research Institute, “JSON Simple Encryption ver.1 draft00,” September 2010.) [JSON_SIMPLE_ENC_1_0] and encrypted for "party" in the request. Personal Information, Contract Part Token and access log MUST be returned in JSON Simple Encryption 1.0 (Protivity Government Services and Nomura Research Institute, “JSON Simple Encryption ver.1 draft00,” September 2010.) [JSON_SIMPLE_ENC_1_0] with using valid public key of specified party.

4.5.1.4.  Access Log Record Format

Every data endpoint MUST provide access log record if it is requested by Signatory. Access log records MUST be also encrypted in JSON Simple Encryption 1.0 (Protivity Government Services and Nomura Research Institute, “JSON Simple Encryption ver.1 draft00,” September 2010.) [JSON_SIMPLE_ENC_1_0].

Access log is JSON structured with followng parameters.

• type
  • OPTIONAL,string(URI)
  • This can be negotiable with this parameter between Parities, but default is http://openid.net/specs/cx/1.0/
• logs
  • Any type because negotiable with "type" parameters.

Default "log" parameter is an array of arrays in which following data are contained in order.

• msg_id
  • Unique identifier for the endpoint given by data providing party.
• request_id
  • Personal information request msg_id specified by requesting party.
• contract_id
  • Contract identifier.
• party
  • requesting party
• datetime
  • requested date and time.
• status
  • response status.
• reason
  • reason of the status

The following is a non-normative sample of access log.

{
     "type" : "http://openid.net/specs/cx/1.0/#access_log",
     "logs"  : [
        [ "http://sp.com/res/4321","http://rp.com/req/343","http://op.com/contract/93",
            "http://rp.com/",'2010-10-13T05:10:38+09:00',"200 OK",""],
        [ "http://sp.com/res/4322","http://rp.com/req/344","http://op.com/contract/93",
            "http://rp.com/",'2010-10-13T05:10:40+09:00',"200 OK",""],
     ]
}

5.  Security Considerations

5.1.  non-repudiation

Since CX is a message oriented public key based signing protocol, it offers non-repudiation unlike plain OpenID Authentication 2.0.

5.2.  Man-in-the-middle

A RP must verify the validity of the OP's identity and public key and vice versa.

5.3.  Eavesdropping

When encryption mode is used, the payload is encrypted and only the real recipient can decipher it. Thus, obtaining sensitive data through eavesdropping is very difficult.

5.4.  Malicious Providers

Malicious Providers that is behaving correctly according to this protocol cannot be coped within this protocol. It has to do the checking of the certificate with some assurance services and/or reputation services including RBL and white list.

5.5.  Phishing Attack

Phishing attack is a social engineering, so it should in principle be dealt with the non-knowledge-based authentication mechanism. This is clearly out of scope of this extension.

5.6.  Private Key Compromise

In the unlikely event of private key compromise, the party should immediately notify the CA as well as the counter party stated in the Contract document. This will minimize the damage by the incident.

Appendix A.  Acknowledgements

6. Normative References

Authors' Addresses