OpenID Trust Exchange Extension
Title: OpenID Trust Exchange (TX) Extension
Convener: Nat Sakimura, Nomura Research Institute
Notes-taker: T Sakushima, NRI America
What Discussed:
- TX protocol in detail especially "Contract" concept
- Why TX and Why not AX?
- Is the name right?
Notes, Key understanding, Questions, Observations, and Action items:
Nat introduced the quote from Gartner. It says that OpenID will continue to be implemented widely, but it will be relegated to low-risk applications unless security weaknesses are addressed and stronger authentication options and secure attribute exchange functionalities are added.”Also says that “Avoid OpenIDfor use in financial transactions and other transactions involving sensitive information.
Data encryption, non-repudiation and audit trailing were the requirements for OpenID when JAL decided to use it for its SSO solution among its affiliates.
The highlights of TX are the following:
- Trust Tokens/Contracts are to be stored as legally binding“contract”that can be produced to authority when necessary.
Contracts are signed by two parties(OP/RP) using defined public key cryptography algorithms such as RSA1024bit, DSA, ECDSA.
- Two bindings (POST and Artifact) to meet both broadband and mobile connectivity requirements.
Artifact binding is a TX's protocol binding to communicate in a back channel because of the limitation of many mobile phones which just handle 128kb of data at a time.
- A default data transfer method (key/value pair and RESTful API) is defined in the spec; however, other methods are can be used as far as specified in the contract.
- The asynchronous/artifact binding/notification features are also considered in TX for mobile phone authentication. In this case, the authN is delivered out of redirection flow for web browsers it is done separately in asynchronous manner.
- TX is actually used for Japan Airline(JAL)'s SSO solution with its affiliates(travel agencies). JAL has 25 million millage club members and 3000 transactions per day are handled.
The basic sequence of TX is as follows:
- An user with a browser visits an e-commerce site(RP) and it triggers regular OpenID authentication(ID/Password authN at an OP) when he checks out the shoppingcart at RP.
- After RP shows an order form and the user decided to purchase(by pressing a "Buy" button) and RP check his current authentication status(if level2, strong authN) and redirects him to another OP for strong authN and value-added services such as payment.
- When the user redirected, the RP sends a "Contract" proposal with terms of usage of his data, its digital signature, and its X509 certificate. The RP also initiates the 2nd authN(strong authN) to the OP with value-added services.
- If the OP verifies the signature on the proposal and agrees it from the RP, the OP creates a response message out of the proposal and add data requested into the proposal. The OP signs it and this proposal becomes the "Contract". The OP sends it back to the RP with its X509 certificate.
- The RP verifies the signature on the contract and use the data based on the terms specified in the contract.
There was the discussion if Attribute Exchange(AX) can be used for a mean to implement TX. Dick Hardt suggested defining the payload schema for TX Proposal/Contract data and passing one-time URL pointing to the data through AX. Dick and David Recordon suggested discussing TX capabilities as a part of the AX WG. The current charter must be modified, but using public keys is the common interest, so it is an option for driving TX.
The name "Trust" is fuzzy, David suggested using a different term. Paul Madsen suggested "Contract Negotiation".
Questions?
Q: What were use cases and requirements for TX when it was initially developed?
- The primary requirement was to protect PII(personal identifiable information). When PII is passed around among parties, agreement of usage and the authenticity is necessary.
Q: In security standing point, SSL protects from eavesdroping and MITM atack when a form is submitted. Why is signature necessary?
- The primary purpose of TX is creation of "contract". Proof of agreement by both parties, non-repudiation, and audit trail are required.
Q: What is "artifact binding"?
- It is passing only handles of data not data itself in back channels. SAML has the same protocol binding.
Q: How does TX manage (public) keys?
- In the current proposal spec, PR's public key is pushed in request messages. OP's public key is published in XRDS.
--
Tatsuki Sakushima
NRI Pacific - Nomura Research Institute America, Inc.
SkypeIn:(650)209-4811
