.Nat Zone

OASIS Open: Submission of requests for Reviews etc.

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

OAuth Wrap Mobile Web App Profile?

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 …

CX on OAuth WRAP

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.

Send CX proposal as an additional parameter on the Verification Code Request. Use wrap_client_id as the proposer’s identifier.
On the PoP verification page, display the terms and conditions included in the proposal.
Create the Verification code from the signature of the proposal and some nonce and random.
Web App Client sends the proposal again as an additional parameter on Access Token Request.
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.

Why is the Artifact 400 bytes?

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.

Attribute Type URI and Script Type

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 …

Essence of Contract Exchange

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 …

OAuth Wrap Web App Profile Summary

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:

wrap_client_id and wrap_client_secret are provisioned from the AuthzServer to the WebAppClient in advance.
An Access Token is an opaque string whose format is agreed upon between the Resource and AuthzServer. It acts as a Bearer Token.
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.

UA …

OpenID Provider Selection Protocol?

In case when the site want to use OP Identifier, the site typically shows list of icons of the OPs. This list grows quickly and results in User Interface Nightmare a.k.a. “Nascar Problem”.

Various people have been working on this, such as IDIB efforts and some Infocard integration, but to me, there seems to be even simpler solution.

I have been wondering why nobody proposes this.
It is extremely simple.

Simply add your OP Identifier to the end of User Agent string, separated by semi-colon. For example, if you are using Safari, and if your OP is mixi.jp, then it would be like:

Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP) AppleWebKit/531.9 (KHTML, like Gecko) Version/4.0.3 Safari/531.9.1;op=mixi.jp

Creating custom header in IE …

Sequence Diagram for Artifact Binding

Based on https://openid.pbworks.com/OpenIDwithArtifactBinding

OpenID Process Change

Finally!

I am glad to write that OpenID Foundation Board has approved the change in the OpenID Process document so that a working group can be started without membership vote.

The change itself requires membership vote, so the notice will go out soon, and it is a month or more away for the new process to get effective, but once that is done, we can spin up WGs pretty quickly. That would certainly help AX 2.0, Auth 2.1 etc.

Re: Is OpenID User Centric?

As I was not able to login to comment on Johannes’s blog…

It is about this entry “Is OpenID User Centric?”.

Johannes’s comment that OpenID being “http://netmesh.info/jernst/digital_identity/is-openid-still-user-centric” is very apt. This is one use case that OpenID is supposed to serve.

The other use case that it is serving right now is the Web SSO.

As a “personal/business card”, you do not need privacy. You do not want privacy. You want to reveal that it was you, and you want to be tracked.

In Web SSO case, you might or might not want to be tracked.

For User Centric thing, I believe that the user should control one’s XRD. Then, I can use Yahoo! or Google as authentication service that provide …

OpenID BizDay #4

I have not been reporting this, but apart from TechNight and BizDay, we are having several discussion groups going on and meetings are getting more like “weekly” than “monthly”. OK. That is not an excuse not writing them here. I will try to be more timely.

Today, I want to report the following:

OpenID BizDay #4

Date: Sept. 25, 2009 (Fri) 14:30 - 16:30
Venue: Vila Fontaine Shiodome Meeting room 2,3
1-9-2 Shinbashi, Minato-ku, Tokyo 105-0021
JAPAN
http://www.sumitomo-rd.co.jp/vf/shiodome/conference/map.html

Program:
“Application of OpenID at NTTCom”
Kazuhiro Kitamura, General Manager, Net Business Div.
NTT Communications Corp.

“gooID that grows with customers”
Yasushi Tsuruki, Manager, Service Dept., Media Div.
NTT Resonant Inc.

To Push or Not to Push: that is the question

So I was designing OpenID Authn Artifact Binding based on OAuth.
OAuth pushes request token (RT) to the Service Provider (saml:responder, openid:op).

Then, I looked back at the saml artifact binding.

It is the opposite. It sends the artifact first and the SP/responder pulls the data from Consumer/requester. Why?

It has got to do with the scale.

When the SP/Responder is big, chances are that the servers are distributed and there will be a big sync up problem among them. Thus, when the RT/message is sent there and the user arrives through browser redirect, the RT/message itself may not be accessible from the server that the user landed.

In case of SAML flow, the requester creates the artifact, and in …

Difference between UMA and CX

This afternoon, I attended UMA WG session at Kantara Initiative. UMA stands for User Managed Access, formally known as ProtectServe.

The purpose of this Work Group is to develop a set of draft specifications that enable an individual to control the authorization of data sharing and service access made between online services on the individual’s behalf, and to facilitate the development of interoperable implementations of these specifications by others.

Thus, it roughly is equal to CX in it’s concept.

A little bit of comparison was done in today’s session.
Most notably:

In CX, contract proposal is sent from the data consumer to the data provider (user) while in UMA, the proposal is being sent from the data provider (user) to the …

What is an OpenID Extension?

OpenID Extension is defined in the section 12 of the OpenID Authentication 2.0 as:

An Extension to OpenID Authentication is a protocol that “piggybacks” on the authentication request and response. Extensions are useful for providing extra information about an authentication request or response as well as providing extra information about the subject of the authentication response.

OK. My question: Does it entirely have to depend on authenticaiton request and response, or can it partially depend on it?

By definition, I think it is the later, because, the subsequent paragraph goes:

OpenID extensions are identified by a Type URI. The Type URI MAY be used as the value of an element of an OpenID element in an XRDS document …

OpenID International Activities Updates

I should be doing this more often:

Japan

- CX discussion group has produced use cases and requirement document on Creative Commons License. Contributors are

Yoichi Ohnawa, NEC BIGLOBE, Ltd.
Takaya Tanaka, KDDI Corporation
Daisuke Ikeda, JCB Co, Ltd.
Takayuki Komatsu, SoftBank BB Corp.
Toru Hada, NEC Corporation
Tatsuo Kudo, Nomura Research Institute Ltd., Editor
Nat Sakimura, Nomura Research Institute, Ltd.
Taizo Matsuoka, Yahoo Japan Corporation
Naoki Koshikawa, Rakuten, Inc.

- Payment Discussion Group is starting in a few week.
As an off spring of the CX Discussion Group, Payment Discussion Group
is starting in Tokyo. It will first evaluate the recent change in the
payment law in Japan, then subsequently disucss the applicability
of OpenID and related technologies on …

Contract Exchange 1.0 Draft 1

Here is my first cut to the Contract Exchange 1.0 (CX) Draft. It is unfinished, and has lots of places needs text, but essence is there, I think.

What is Identity?

From this morning, there is a thread going on on Identity Commons mailing list (identity gangs) on “What is Identity?”.

The thread started off by quoting Kim Cameron’s definition of Digital Identity.

Digital Identity: the digital representation of a set of claims made by one digital subject about itself or another digital subject.

Then, Bob Blakly paraphrases American Heritage Dictionary in the same thread as:

the set of characteristics by which a thing is generally recognized or known

These two seems to be in a general agreement, but I would like to dig a little more because I have a bit of problem with this definition.

When we talk about a term, it is always useful to get back to its …

Discussion Note on Contract Exchange

Here is the discussion note that I wrote for Contract Exchange.

http://openid.net/pipermail/specs-cx/attachments/20090730/8d9862f8/attachment-0001.pdf

Hopefully, the concept is quite clear and it acts as the level setting ground for the participants at specs-cx.

XRD as of July 22.

According to the current XRI TC discussion, it is looking like this.

<xrd>
<Subject set="beginswith”>…</Subject>
<Alias>…</Alias>
<KeyDescriptor use="*”>
<ds:KeyInfo>
…
</ds:KeyInfo>
</KeyDescriptor>
<ds:Signature>
<ds:KeyInfo>
…
</ds:KeyInfo>
</ds:Signature>
<link>
<rel>…</rel>
<uri>…</uri>
…