This extension allows two parties(数を特定。２以上ならmultiple。or a COP and a CAP) to exchange a mutually signed assertion, a.k.a. "Contract" that authorizes services or data usage between(２以上ならamong) web sites.
The Trust Exchange extension provides confidentiality of data transmissions and non-repudiation of claims by public key cryptography. If RPs employ proper logging functionalities to bind logs to Contracts, transmissions to a COP MAY be audited by a data owner at a CAP or third party authorities.
Contracts must be signed with digital signatures by both a COP and a CAP(読み手による解釈の余地がないように、特定の用語を使う。). In this version of Trust Exchange extension, it adopts "Proxy Signatures" which the COP signs on behalf of an user, and the CAP signs on behalf of a data owner since many devices like cellular phones are not capable to sign at this moment. However, the direct signing should be considered so that the use cases will be expanded.
Contracts will be concluded in the following manner:
1. Offer Creation
(ここにCOPでのuserとUser Agentの振る舞いをいれるとわかりやすい) A COP creates an Offer to ask for a Service to a CAP. An user of the COP specifies the address of the Service by URI or XRI. The COP discovers the Service and its endpoint by using Yadis or XRI resolution. Also, the COP can(OverviewではNotationsは使わない) prepare a list of the services which the COP knows their endpoints and ask a user to choose the service he/she wants to use.
An Offer must include a digital signature signed by COP's private key as well as the X509(certの種類を特定) certificate(including the COP's public key) for the signature. Or an Offer can specify an address to get the certificate(?) from the third(公式文では3rdとか略語は使わない) party security authories.
2. Sending Offer（ラベルをすべて名詞句へ変換し表現を合わせる）
The COP sends the Offer to the CAP's endpoint through HTTPS POST. The CAP returns the Ticket which identifies the Offer. It is encrypted with the COP's public key.
3. Initiating Confirmation request
The COP sends(redirects? with) a Location URI(a Confirmation request?タイトルにあるのに本文に説明がでてこない) to an User Agent(急に登場してきたように見えるので、１に説明を加える。). The URI includes the OpenID TX namespace and the Ticket.
4. Processing Confirmation request
When the CAP receives the Confirmation request(3に説明を加えて、theとする) (from who?), the CAP fetches the Offer with the Ticket from database and retrieves the COP's public key from the certificate in the Offer. (4から5への説明が抜けている)
If the Offer is not found or the Confirmation request is invalid, the CAP sends back a contract cancel status message to the COP through the indirect response(?) with the User-Agent.
5. Authentication
(4からどのようにしてユーザー認証が始まるのか？わからない)The user is authenticated by the CAP using [OpenID Authentication 2.0].
If the authentication failed, the CAP sends back a contract cancel status message to the COP through the indirect response with the User-Agent.
6. Access Authorization
If the user is valid, the CAP checks policies and if the data specified in the Offer can be accessed by the user.
If the access does not meet policies, the CAP sends back a contract cancel status message to the COP through the indirect response with the User-Agent.
7. Completing Offer to Contract
If the user(正確には誰に許可？the COP?) is authorized to use the Service, the CAP signs the Offer with its private key and attaches the corresponding certificate so that the Offer becomes a "Contract". Also the CAP generates a Contract identifier for the Contract and stores in database. The contact is sent in a contract complete response back to the COP.
If the contract is completed by a third persionr's(?) authorization later ( e.g, the Service uses his private data ), the CAP send a "pending approval" message back to the COP through the indirect request with the User-Agent. The COP can request a data transmission to the CAP only after the CAP notifies a contract complete message to the COP's Endpoint.
8. Initiating Accepting response.
If the Contract is successfully completed, the CAP composes a complete response with the Contract identifier and sends it to the COP indirectly using the User-Agent(redirectといってしまう方がわかりやすくないか？).
If the Contract is not completed during the processing request, authentication, or authoraization, the CAP returns a status code in the response.
9. Processing Accepting response.
The COP checks the contract status in the response message submitted by the CAP. If the contract is cancelled, the COP display the error message to the End User.
10. Conclusion(ここの説明はちゃんと理解できているか自身がないです)
On the successful completion of the contract, the COP makes a HTTPS GET(?) request to CAP's endpoint directly to obtain the contract. The Contact is encrypted with the COP's public key. The COP can decrypts the Contract with its private key and retrieve a shared key(データ暗号化のための共有鍵が突然でてくる印象。どのように生成したか？も書くべき。それか「ここにデータ交換プロトコルで使う共有鍵もしまえますよ」的な説明にする。). The COP decrypt the Contract envelop with the shared key and verify the signature of Contract with CAP's public key.
If the Contract is valid, the COP securely stores it for a legally required period.
11. Execution（Data Access？）
The COP with the valid Contract can request the Service to the CAP under the condition written in the Contract. (access requestの中の何を検証しているのか？書くべき)
In many cases of the Contract transmission(Conclusion), the shared key encrypted by the COP's public key should be transmitted first and the data itself encrypted by the shared key should follow it.
Some Services provided by a CAP may use other protocols to transmit data. In such a case, a COP must follow the procedures to request the Services. Additional protocol and procedure details MUST be stated in XRDS in the Services.
12. Notification.
If a COP want to be notifed some messages from a CAP, it can declare its Notification Endpoint in a Offer. A CAP notifies a COP by sending messages to this endpoint. (プロトコルは何を使う？PUT？)
How to apply Notification services(何が書かれているのか？インストラクション、設定情報？) should be stated in XRDS of CAP's Service and a COP should follow it.
Approval-based authentication in TX(Approval-based authenticationについて、もう少し詳しく説明する) is implemented in this mechanism.
This extension allows two parties(数を特定。２以上ならmultiple。or a COP and a CAP) to exchange a mutually signed assertion, a.k.a. "Contract" that authorizes services or data usage between(２以上ならamong) web sites.
The Trust Exchange extension provides confidentiality of data transmissions and non-repudiation of claims by public key cryptography. If RPs employ proper logging functionalities to bind logs to Contracts, transmissions to a COP MAY be audited by a data owner at a CAP or third party authorities.
Contracts must be signed with digital signatures by both a COP and a CAP(読み手による解釈の余地がないように、特定の用語を使う。). In this version of Trust Exchange extension, it adopts "Proxy Signatures" which the COP signs on behalf of an user, and the CAP signs on behalf of a data owner since many devices like cellular phones are not capable to sign at this moment. However, the direct signing should be considered so that the use cases will be expanded.
Contracts will be concluded in the following manner:
1. Offer Creation
(ここにCOPでのuserとUser Agentの振る舞いをいれるとわかりやすい) A COP creates an Offer to ask for a Service to a CAP. An user of the COP specifies the address of the Service by URI or XRI. The COP discovers the Service and its endpoint by using Yadis or XRI resolution. Also, the COP can(OverviewではNotationsは使わない) prepare a list of the services which the COP knows their endpoints and ask a user to choose the service he/she wants to use.
An Offer must include a digital signature signed by COP's private key as well as the X509(certの種類を特定) certificate(including the COP's public key) for the signature. Or an Offer can specify an address to get the certificate(?) from the third(公式文では3rdとか略語は使わない) party security authories.
2. Sending Offer（ラベルをすべて名詞句へ変換し表現を合わせる）
The COP sends the Offer to the CAP's endpoint through HTTPS POST. The CAP returns the Ticket which identifies the Offer. It is encrypted with the COP's public key.
3. Initiating Confirmation request
The COP sends(redirects? with) a Location URI(a Confirmation request?タイトルにあるのに本文に説明がでてこない) to an User Agent(急に登場してきたように見えるので、１に説明を加える。). The URI includes the OpenID TX namespace and the Ticket.
4. Processing Confirmation request
When the CAP receives the Confirmation request(3に説明を加えて、theとする) (from who?), the CAP fetches the Offer with the Ticket from database and retrieves the COP's public key from the certificate in the Offer. (4から5への説明が抜けている)
If the Offer is not found or the Confirmation request is invalid, the CAP sends back a contract cancel status message to the COP through the indirect response(?) with the User-Agent.
5. Authentication
(4からどのようにしてユーザー認証が始まるのか？わからない)The user is authenticated by the CAP using [OpenID Authentication 2.0].
If the authentication failed, the CAP sends back a contract cancel status message to the COP through the indirect response with the User-Agent.
6. Access Authorization
If the user is valid, the CAP checks policies and if the data specified in the Offer can be accessed by the user.
If the access does not meet policies, the CAP sends back a contract cancel status message to the COP through the indirect response with the User-Agent.
7. Completing Offer to Contract
If the user(正確には誰に許可？the COP?) is authorized to use the Service, the CAP signs the Offer with its private key and attaches the corresponding certificate so that the Offer becomes a "Contract". Also the CAP generates a Contract identifier for the Contract and stores in database. The contact is sent in a contract complete response back to the COP.
If the contract is completed by a third persionr's(?) authorization later ( e.g, the Service uses his private data ), the CAP send a "pending approval" message back to the COP through the indirect request with the User-Agent. The COP can request a data transmission to the CAP only after the CAP notifies a contract complete message to the COP's Endpoint.
8. Initiating Accepting response.
If the Contract is successfully completed, the CAP composes a complete response with the Contract identifier and sends it to the COP indirectly using the User-Agent(redirectといってしまう方がわかりやすくないか？).
If the Contract is not completed during the processing request, authentication, or authoraization, the CAP returns a status code in the response.
9. Processing Accepting response.
The COP checks the contract status in the response message submitted by the CAP. If the contract is cancelled, the COP display the error message to the End User.
10. Conclusion(ここの説明はちゃんと理解できているか自身がないです)
On the successful completion of the contract, the COP makes a HTTPS GET(?) request to CAP's endpoint directly to obtain the contract. The Contact is encrypted with the COP's public key. The COP can decrypts the Contract with its private key and retrieve a shared key(データ暗号化のための共有鍵が突然でてくる印象。どのように生成したか？も書くべき。それか「ここにデータ交換プロトコルで使う共有鍵もしまえますよ」的な説明にする。). The COP decrypt the Contract envelop with the shared key and verify the signature of Contract with CAP's public key.
If the Contract is valid, the COP securely stores it for a legally required period.
11. Execution（Data Access？）
The COP with the valid Contract can request the Service to the CAP under the condition written in the Contract. (access requestの中の何を検証しているのか？書くべき)
In many cases of the Contract transmission(Conclusion), the shared key encrypted by the COP's public key should be transmitted first and the data itself encrypted by the shared key should follow it.
Some Services provided by a CAP may use other protocols to transmit data. In such a case, a COP must follow the procedures to request the Services. Additional protocol and procedure details MUST be stated in XRDS in the Services.
12. Notification.
If a COP want to be notifed some messages from a CAP, it can declare its Notification Endpoint in a Offer. A CAP notifies a COP by sending messages to this endpoint. (プロトコルは何を使う？PUT？)
How to apply Notification services(何が書かれているのか？インストラクション、設定情報？) should be stated in XRDS of CAP's Service and a COP should follow it.
Approval-based authentication in TX(Approval-based authenticationについて、もう少し詳しく説明する) is implemented in this mechanism.