There has been some talk around Attribute Type URI couple of months ago in OpenID mailing lists. Unless we define a set of widely agreed Type URIs, we will not be able to transfer attributes insuperably. Chris Messina’s summary document on various type URI is very helpful to compare these.

There however is one thing that these specs are missing. The Script types and the language.

Unlike most Western language, some language like Japanese have many scripts within itself. For example, we use “Kanji”, “Katakana”, “Hiragana”, “Romaji (alphabet)” as four distinctive scripts. Often, we are required to supply name and address both in Kanji and Katakana or Hiragana, because without Katakana or Hiragana, you really do not know how to pronounce the Kanji in many cases.

Thus, while it would probably suffice to express fullname just as

http://axschema.org/namePerson

in English, we need these in each scripts.

The problem is how to express these as Type URIs.

One obvious way of approaching it would be something like

http://axschema.org/namePerson#script_name/language_code

where script_name and language_code are optional.

For example,

http://axschema.org/namePerson#kanji
http://axschema.org/namePerson#katakana

would be the Kanji and Katakana version of the fullname.

If the default language for those were not specified, we could further qualify them as

http://axschema.org/namePerson#kanji/ja_JP

If there is only one script for the language, or if it does not matter, we could abbreviate like:

http://axschema.org/namePerson#/en_US

which is the same as

http://axschema.org/namePerson

if the default language was specified as en_US.

What would you think?

Abstract

This article describes the concept of (abstract) Contract Exchange, and then discusses the OpenID Binding and Use of the Contracts as Access Tokens. At the end, it also provides a mapping table to User Managed Access (UMA) Terminologies.

About Contract Exchange

Contract Exchange (CX) is a protocol to exchange the signed contract dynamically among the entities in the network. It uses Public Key based signature, so it achieves certain degree of the non-repudiation and ability to prove. Thus, e-commerce etc. should benefit from it. In addition, since it can capture the purpose of the use, condition of the use, provisioning method etc. for the data/attributes, it can be used to achieve the server to server exchange of the data.

Draft OpenID CX is a binding of this Contract Exchange onto OpenID. It takes a form of OpenID Extension. Thus, it can be used over the existing OpenID Authentication 2.0, which is a GET/POST binding, as well as over the artifact binding which has been discussed since last fall. For the exchange of the proposal and contract etc., it is also using Attribute Exchange 1.1 Draft.

Basic Flow of the CX.

The basic flow of the CX has the following flow. Note that this is before binding it to a specific underlying protocol.
In the below, AM stands for Authorization Manager, SP for Service Provider.

1. (SP finds Proposal Template from XRD/S of the AM)
2. SP obtains the proposal Template from the AM.
3. SP specifies the variables in the Proposal Template to create a Proposal.
4. SP signs the Proposal to create a Signed Proposal.
5. SP sends the Signed Proposal to the AM.
6. AM shows the conditions to the user and obtains the authorization.
7. If OK, the AM counter-signs the proposal to create a Contract.
8. AM saves the Contract and sends a copy to the SP.
9. SP uses the Contract to obtain data etc. and provides service to the user.

The service does not necessarily require data transfer. It may even not a service over the network.
However, it is expected that in majority of the cases, it will be a network based service that requires some data transfer.
Under such circumstances, some data transfer protocol needs to be defined in the contract. e.g., OpenID AX, OAuth, Wrap “API Calls”.)

Characteristics of the CX Template

CX Templates has several unique features.

• XML is the default format.
• The template has to have a URL of the form http://uri_of_contract_template#digest_algorithm:digest, so if the template is changed, the url will also change.
• Anyone can create a template, but since AM is the party that knows what data is available as well as the party which creates the permission page, AM seems to be the natural place.
• As the result of the Hashed URL, template cannot be edited. Thus, we have to use variables to express the portion which is given from the outside.
• Template variables are expressed in the form of {{variable_name}}. As the variable name, xs:id of the XML element is used, and the value will be the inner text of the Element.

Characteristics of the CX Contract

• There can be as many parties as one wants. That is, we can express n-party contract. Each Party has Obligations.
• A Contract includes the public key of the each Parties. These can be used for the signature verification and data encryption.
• A Contract includes a TemplteURL and a Template. Ops and RPs can use this TemplateURL to figure out what kind of template it is.
• Obligation can be written in the Contract. This includes the price and damage limit.
• As a default data request method, AX Request is supported. Other format can be defined.
• Signature is done by XML Signature. Canonicalization is Exclusive Canonicalization. Since it is using the Digital Signature, the ability to proof is high even outside the system.

OpenID GET/POST Binding

CX can be bound to OpenID through GET/POST Binding and Artifact Binding. For the purpose of this article, which binding to use is a non-issue, so I am using simpler GET/POST binding flow.

In the next diagram I am using OP (OpenID Provider) instead of AM and RP (Replying Party) instead of SP to match the OpenID terminology. In addition, UA stands for User-Agent (e.g., Web Browser).

Data Transfer using CX

In the use case that transfers data, CX Contract can be used as either the holder-of-key or bearer access token by the RP. Alternatively, if the Data Provider has the copy of the contract, then ContractID can be used as a bearer token. (In general, AM and DP are different, so the later cannot be assumed in every case.) Using such Tokens, server to server data transfer can be achieved. Data Provider (DP) checks the authenticity of the contract and then creates a dataset and encrypts it with the public key in the Contract and provides it to the requestor. Since it is encrypted by the public key of the intended recipient, it cannot be read by somebody else.

Appendix 1: Mapping to UMA terminology

Here is the Sequence Diagram of OAuth Wrap Web App Profile (Section 5.4).

Hope the spec to include such instead of legacy ascii diagram…
websequencediagrams.com source would do.

Notes:

1. wrap_client_id and wrap_client_secret are provisioned from the AuthzServer to the WebAppClient in advance.
2. An Access Token is an opaque string whose format is agreed upon between the Resource and AuthzServer. It acts as a Bearer Token.
3. All the communication is done over HTTPS so signatures are said to be unnecessary. (I am skeptical on it though. [*1])

[*1] Security Questions

It might be because I have not spent too much time on this protocol, and I was writing this (original Japanese version) at 2:00AM, I have some questions on the security characteristics.

1. UA may act as the man-in-the-middle to tamper the request. (e.g., when the UA is infested by a malware.) To me, it seems that it can only be coped by either the request to be signed or something like an Artifact is used instead of the request itself. Since the target of WRAP is to remove the signature, the Artifact seems to be the way to go.
2. To identify the client, it is using client_id and client_secret. It is essentially a username/password authentication. Thus, from the NIST SP800-63 like perspective, it is only LoA1.
3. Access Token is another long-term secret. Moreover, it is revealed to somebody else than the client and the verifier (AuthzServer). It has some implication from the SP800-63 perspective.
4. MITM is possible even for HTTPS. How to recognized that the counter party is the right one needs to be specified in more details. Certificate Chain verification is only a necessary condition. If it is not done correctly, it will be possible to mount token capture and replay attack.
5. Access Token is specified only as an Opaque String. This actually needs to be specified a little more in detail. For example, randomness requirements, signature requirements etc. are needed to thwart the guessing attack and the access token forgery.
6. Browser Swap / CSRF attack has to be thwarted.

Much of these needs to be dealt with Section 7. Security Considerations.

In addition, I have not understood

1. Why are we provisioning wrap_client_id and wrap_client_secret out of band? The y can just be Subject and Pubkey of XRD. If we do so, the long-term client_secret problem disappears, though signature resurfaces.
2. Why do not we standardize on Scope format? For AuthzServers, having no standard is ok, but for WebAppClients, it is much easier to code on the standard than code a proprietary request per AuthzServer.