Trusted Data Exchange

Author: =masaki, =nat

Contents 1 Background 2 Protocol Overview 3 Data Format 4 Reputation 4.1 Reputation Request 4.2 Reputation response 5 Contract proposal 5.1 Contract proposal request 5.2 Contract proposal response 6 Contract 7 Data Transfer 7.1 Data transfer request 7.2 Data response XML

Background

OpenID is designed for an open and worldwide framework of authentication including single-sign-on. Sreg and AX are extensions bringing capability to share “casual” information such as nicknames, gender or street address (in U.S) between OP and RP. Exchanging more sensitive information will require OP to be more responsible for protecting its users from attacks such as Phishing, Man-in–the-Middle attacks, etc. OPs will be regarded as “data authorities” of user privacy information. In addition, in some countries (Japan and perhaps EU), even street address is considered as one of the sensitive (e.g., privacy) information so that to communicate the data, it has to go with the permission (contract) stating the purpose of use (and period). (One is not allowed to give this information to a third party without explicit consent of that person = data owner.)

Thus, we need some extention that bringus us more Security and Trust.

They are not abstract requirements.

They are the real user requirement that we have to implement in couple of month time.

Protocol Overview

Following diagram depicts the main protocol flow.

The sequence is as follows:

1. . Post End Users Identifier (OpenID) to the RP
2. . Resolution of the OP
3. . Association between OP and RP
4. . AuthN Request with openid.tx.policy_url, openid.realm, and optionally AX data request.
5. . OP makes a reputation request for the RP with openid.realm.
6. . OP gets the reputation score for the realm together with the public key of the RP.
7. . OP requests RP the policy that includes Contract proposal incl. what data, purpose, expiry, etc. (see Contract section above.)
8. . RP responds with the signed proposed policy.
9. . OP prompts the user agent whether to accept the policy.
10. . User responds with Yes or No. If Yes, it will be signed.
11. . OP returns AuthN response with openid.tx.contract_handle (and ax data if there were any.)
12. . RP request the data with the contract_handle.
13. . OP (in this example... could be other attribute authorities) returns data (which includes contract handle and signed by the authority)

Data Format

There are several data structures involved. Namely:

1. Reputation
2. Policy (Proposed Contract)
3. Contract
4. Data Exchange (Based on Contract)

In each of the above, there will be request and response format.

Reputation

Reputation Request

Reputation data for RP is sent to Reputation server as a REST request via HTTPS. OP should verify RS matching SSL certification to the cert list of pre-trusted RPs.

Parameters

• id (required)

id is used to identify the subject of which the requesting entity (OP) is going to get reputation. id should be an URI, or un-urized XRI. If the RP identifier exist in authentication requset, OP copy it to this parameter. If not, use openid.realm instead.

Sample

• realm

https://reputation.service.provider/service/endpoint/url?id=http%3A%2F%2Frealm.of.rp%2F*

• XRI

https://reputation.service.provider/service/endpoint/url?id=%40RP%2Fservice

Reputation response

Reputation response is a XML document. Reputation response. For details, refer to OpenIDReputationService .

Contract proposal

Contract proposal request

Policy request is also REST. OP simply extract policy_url from authentication request and make a http GET request to it.and receive RP returnds a policy statement XML document (contract proposal). The XML is defined capable for RP to sign it, so if the sign exist, this request does not need SSL.

Contract proposal response

Policy response / contract proposal XML contains following factors.

• List of requesting parameters (data class such as 'street address' or 'first name')
  • For each parameter, a mark 'required' or 'optional'.
  • XRI can be used to identify data class like - '@SOMEONE/(+address)*($v.1.0)'.
• RP statement, detailed description of privacy policy, in human readable form.
• (Probably) machine readable policy description.
• Policy issuing date and RP's signature.
• RP need to

<xml xmlns="=xri://$xrcp*($v*1.0)">
  <ContractProposals issuer="@RP">
    <ContractProposal type="@RP/EnduserInformationDiscrodure">
      <IssuedDate>
        2007-12-25T12:34:56+09:00
      </IssuedDate>
      <PolicyDescription>
        Human readable policy statement is here.
      </PolicyDescription>
      <CompactPolicy>
        MACHINE_READABLE_POLICY
      </CompactPolicy>
      <RequerstingAttributes>
        <Attribute type="@RP/(+firstname)($v*1.0)" required="true">
          <DisplayName lang="ja_JP">
            First Name
          </DisplayName>
        </Attribute>
        <Attribute type="@RP/(+email)($v*1.0)" required="true">
          <DisplayName lang="ja_JP">
            e-mail Address
          </DisplayName>
        </Attribute>
      </RequerstingAttributes>
      <AutoUpdate request="true" />
      <Signature xmlns="http://www.w3.org/2000/09/xmldsig#" >
        [XML Signature for ContractProposal]
      </Signature>
    </ContractProposal>
  </ContractProposals>
</xml>

Contract

OP make an interaction with the end-user and sign to the contract proposal on behalf of the user if it agreed to the proposal. In this phase, user may set expire date of this contract and choose which types to disclose.

After signing, OP store whole XML contract and return the contract handle to the RP over auth-response.

• contract_handle

Contract_handle is a value points to a contract. It must be unique in OP.

<xml xmlns="=xri://$xrcp*($v*1.0)">
  <Contract Id="@OP/(+contract)*($v*1.0)/0123456789">


    <ContractProposal type="@RP/EnduserInformationDiscrodure">
      <IssuedDate>
        2007-12-25T12:34:56+09:00
      </IssuedDate>
      <PolicyDescription>
        Human readable policy statement is here.
      </PolicyDescription>
      <CompactPolicy>
        MACHINE_READABLE_POLICY
      </CompactPolicy>
      <RequerstingAttributes>
        <Attribute type="@RP/(+firstname)($v*1.0)" required="true">
          <DisplayName lang="ja_JP">
            First Name
          </DisplayName>
        </Attribute>
        <Attribute type="@RP/(+email)($v*1.0)" required="true">
          <DisplayName lang="ja_JP">
            e-mail Address
          </DisplayName>
        </Attribute>
      </RequerstingAttributes>
      <AutoUpdate request="true" />
      <Signature xmlns="http://www.w3.org/2000/09/xmldsig#" >
        [XML Signature for ContractProposal]
      </Signature>
    </ContractProposal>
 
    <TimeStamp>
      2007-12-25T12:34:56+09:00
    </TimeStamp>
 
    <ContractConclusion type="@RP/EnduserInformationDiscrodure">
      <Attributes>
        <Attribute type="@RP/(+firstname)($v*1.0)" />
        <Attribute type="@RP/(+email)($v*1.0)" />
      </Attributes>
      <AutoUpdate Permit="true" />
      <ExpireDay>
        2007-12-25T12:34:56+09:00
      </ExpireDay>
    </ContractConclusion>

    <Signature xmlns="http://www.w3.org/2000/09/xmldsig#" >
      [XML Signature for ContractProposal and ContractConclusion]
    </Signature>

  </Contract>
</xml>

Data Transfer

Data transfer request

Once RP receives contract handle, RP can make a request to OP for user data. If the returning data would be encrypted, RP can simply append contract_handle to OP's service endpoint URL and use GET request on normal HTTP. Without datga encryption, RP must use SSL and send nonce and signature to prove itself. RP also obtain contract body (XML document) through this request, whether the response include contract or not will be decided with parameter mode.

• contract_handle

Contract_handle delivered to RP.

• nonce (optional)

Nonce difined by RP begins with timestamp.

• signature (optional)

OpenID signature of concatnation of contract_handle and nonce.

• mode (optional)

contract_only, data_only or both. If absent, data_only supposed.

Data response XML

• Attribute

<Attributes>
  <Attribute type="@RP/(+firstname)($v*1.0)" required="true">
    [Attribute Value]
  </Attribute>
  <Attribute type="@RP/(+email)($v*1.0)" required="true">
    [Attribute Value]
  </Attribute>
</Attributes>

• Data XML

<xml xmlns="=xri://$xrcp*($v*1.0)">
  <DataExchange ContractHandle="@OP/(+contract)*($v*1.0)/0123456789">
   
    <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'
      Type='http://www.w3.org/2001/04/xmlenc#Element'/>
      <EncryptionMethod
        Algorithm='http://www.w3.org/2001/04/xmlenc#tripledes-cbc'/>
      <ds:KeyInfo xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
        <ds:KeyName>
          John Smith
        </ds:KeyName>
      </ds:KeyInfo>
      <CipherData>
        <CipherValue>
          DEADBEEF
        </CipherValue>
      </CipherData>
    </EncryptedData>

    <Signature xmlns="http://www.w3.org/2000/09/xmldsig#" >
      [XML Signature for ContractProposal and ContractConclusion]
    </Signature>

  </DataExchange>
</xml>