Just a personal memo on OASIS process as one of the TC chair, but OIDF should develop this kind of chart as well, I think.

Due to an ever-increasing workload I must ask that each request be sent in a separate e-mail message unless related to a single, multi-part specification. As a reminder, a chart showing exactly what needs to be included with each request can be seen here:
http://docs.oasis-open.org/templates/MindMaps/TCAdminRequestNotices/index.html

To ensure the quickest possible handling of your request, make sure to
1. review the checklist: http://docs.oasis-open.org/templates/QAChecklistV3.html
2. Include the requisite information in the request:
http://docs.oasis-open.org/templates/MindMaps/TCAdminRequestNotices/index.html
3. do not include more than 1 document in any single request.

Thank you for understanding.

Regards,

Mary

The wrap_scope, especially when it is determined dynamically using standard vocabulary such as something similar to OpenID AX, can become quite big. Under such circumstances, we may hit the browser/server constraint on URL and HTTP header. This is more acute in the mobile scenario.

Lucky thing is that it is trivial to create an Mobile friendly profile / binding of OAuth Wrap, since it is almost done. It suffices just to introduce a request artifact.

Here is the flow:

(fig.1) Wrap Mobile Web Profile

Of course, details need to be nailed down, but the basic flow should be it.

People may criticize that it introduce state in the AuthzServer. It may, but it is not necessarily so. Since the AuthzServer knows what it can serve, it has constrained set of scope and may well be able to encode it into an Artifact, so that it does not need to keep the state.

–
(Feb 12) Fixed typo in the figure.

Like there can be OpenID GET/POST and Artifact Binding for CX, there can be WRAP binding as well. It is fairly trivial, arguably more trivial than to define OpenID bindings.

1. Send CX proposal as an additional parameter on the Verification Code Request. Use wrap_client_id as the proposer’s identifier.
2. On the PoP verification page, display the terms and conditions included in the proposal.
3. Create the Verification code from the signature of the proposal and some nonce and random.
4. Web App Client sends the proposal again as an additional parameter on Access Token Request.
5. Sign the proposal to create the contract, serialize it with Base64 without line end, and return it as the access token on Access Token Response.

That’s all.

In the current Artifact Binding manuscript, the artifact is being defined as a string shorter than 400 bytes. Some people asked why 400 and not 512, which is the limit of some mobile browsers?

The answer is that we use 80 bytes in the fixed string:

?openid.ns=http://specs.openid.net/auth/2.0&openid.mode=art_res&openid.artifact=

Suppose we use 400 bytes in Artifact. Then, the total is 480 bytes.
That leaves 32 bytes to the non-query portion of the URL.

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?