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?

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.

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 is a bit of problem, but the UA string is an exception and can be changed just by changing a registry entry as far as I know. Most other major browsers provide ways to set the user agents.

The RP, upon receipt of the above string, extracts mixi.jp and redirects user to mixi.jp automagically. If he has a session there, which is likely, he may be returned to the site immediately.

True that it reveals your OP to every site. Some people may consider it a privacy problem, and some would complain about the security implication, but how real would be an attack using that information? Not much, I think. Anti-Phishing? It should be dealt with other mechanisms.

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

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.

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 PPID.

If I want to preserve anonymity, I would use OP identifier to Yahoo! or Google. Alternatively, I could provide an XRD address that service PPID, but that would be a tall order for most people.

If I want to leave my track, then I will provide my (signed) XRD address.

As to the email as attribute being sent…

I think we should define contact service just like XRI people do. It could be email, twitter, or authenticated something, etc. The service should be advertised in the XRD. Then we should not need to provide “physical” address like email to the RP.

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.

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 the artifact, there is a node index included. Then, user arrives to the responder with artifact, and the responder pulls the data using this artifact. When requester receives the artifact, it knows where the RT/message is stored, so it can reliably fetch it.

So, SAML actually is kinder to a large scale providers.

On the other hand, OAuth has its own edge. In case of OAuth, the Requester always makes the action. It does not matter if it is behind the firewall or something. Typically, if it is an application living on a PC or Phone or something like that, the chances are that SP/Responder/OP cannot reach the client because it has got a private address. Since OAuth had such use case from the beginning, I suppose, the current choice was made.

So, coming back to OpenID Artifact Binding: Which design should we chose?

To Pull, or to Push: That is the question.

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 data consumer.

This is subtle but important distinction, at least, philosophically.

In fact, when I started discussing CX among my friends, we first consider the user providing the policy just like UMA. It was because it is closer to the VRM like setting. Then, after a while, we made a conscious decision to do the other way round.

Why?

In most cases, the data consumer is actually web service. It is a machine. On the other hand, on the data provider side, there is the user, the human being, who makes the decision.

If we offer a contract proposal from the user side, the machine has to negotiate it automagically. It is hard.
It looked like it is an daunting task to do it over a wide range of possible use cases.

On the other hand, the other way round is easy. You show the user the condition and terms, and it is this human being parsing that proposal and making decision. This seemed like a reasonably easy thing to achieve technically.

To approximate user providing the acceptable policy, we can create a common repository of contract proposals and the user can publish the URL in his XRD, so that the data consumer can pick an acceptable policy.

I believe this approach saves us from the hard question of designing negotiation protocol and still achieve something roughly the same. Also, note that we do not have to agree on the syntax of the machine readable condition. It is up to the application to decide it(*1).

We are right now doing CX WG at OpenID Foundation. However, CX is not only for OpenID. I consider it as an OpenID Binding of CX. It can equally be done for OAuth or some other protocol.

UMA’s approach is definitely interesting, but I still do not know how it can be achieved. It is a “must track” kind of thing for me right now.

(*1) There was yet another reason to do it this way: I was not comfortable floating around a contract proposal signed by me waiting for some unknown party to counter-sign floating around. From the “consumer protection” (note different use of the term “consumer") perspective, IMHO, the user should be the last one to sign.

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 associated with a Claimed Identifier. The Type URI is also used to associate key-value pairs in messages with the extension.

Clearly, this is not authentication request (section 9) and response (section 10), but Discovery (seciont 7.3). Thus, if it were to be entirely on request and response, the spec contradicts itself.

Therefore, it has to mean that an extension is a protocol that has to utilize request and response.

QED

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 it.

- Ministry of Internal Affairs and Communication has published a request for public comment on the coming substantiative experiment which involves OpenID and SAML interop and uses in Telecos and other entities. (Aug. 6)

- Ministry of Economy, Trade and Industry has put a tender for substantiative experiment on Government-Private Sector Authentication and Identity interoperability, which is likely to be OpenID. (Aug. 4)

- NRI and Verisign Japan announced their intent to start high assurance authentication service based on mobile phone identification, risk based authentication, etc. over OpenID. (Aug. 6)

- NTT has announced that it will support OpenID as “NTT Single Signon Service”. When the service opens, it will be the largest OpenID provider in Japan with over 70 million users. (May 12)

- Numerous miscellaneous press coverages and seminars. We stopped counting them at OIDF-J because there are too many now. OIDF-J now has 52 member companies spanning from the telcos, banks, retailers, transportation, IT, etc.

Europe

- In June, Robert Ott has become the Vice President of OIDE, and is the acting head of OIDE now, as Snorri is extremely busy right now to run his family’s business after his father passed away late last year.

- Jean-Noel Colin is now the representative for Belgium

- OIDE will be representing OpenID in OpenID at EMEX Suisse.

- In autumn, Robert Ott will present OpenID at a Security Event in the IBM innovation center here in Switzerland.

- The major Dutch social website Hyves released it’s support for OpenID in April.

- “OpenID, put into practice” held in Amsterdam, May 12, was a great success.

- CloudViews 2009 held in O Porto, where Nat Sakimura was an invited speaker on identity.

- The largest Portuguese Portal now supports OpenID.

I am pretty sure I am missing many important news. Please let me know so that I can keep the list updated.

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.

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 root. The below is an excerpt from my lecture at Security Expo 2009 Tokyo.

The term “identity” first appeared in documents around 1570. It was a term that was derived from middle age french word identité, which was in tern formed from 5th century Latin Identitatem. Identitatem was a combined word of “idem et idem”, where “idem” is “same”. From this, it is apparent that the central notion of “identity” in fact is the “sameness”.

This is captured in the “Principle of Identity of Indiscernibles” by Gottfried Wilhelm Leibniz, (1646 ? 1716) .

Subject x and y are identical if any predicate possessed by x is also possessed by y and vice versa.

i.e.,

(1)

This is rather controversial.

Clearly, The indiscernibility of identicals:

(2)

holds, but not the identity of indiscernible.

To illustrate it, I have depicted the relationship between Subject and identity (partial identity) in the following figure.

In this figure, I have represented Subject as a molecular structure. It is there, but we cannot observe it directly because whenever we observe, it is merely a projection of it onto the cognitive surface or hyper-plane. Unfortunately, this mapping/projection is not one-to-one. Different Subject can map onto the same thing on a cognitive surface/hyper-plane, i.e.,

Two objects having same identity may NOT be identical.

This sound contradictory.

From (1) and (2), it is clear that to have the proposition

Two objects having same identity is identical

hold, it has to be Subject=Identity.

Of course,

Two objects having same partial identity may NOT be identical.

We sometimes call this “Partial Identity” a “Persona”.

The problem of American Heritage definition probably is that it is supposing there is a general cognitive plane (generally recognaized). There is no such thing in practice, unfortunately.

References:
Definition of identity?, http://lists.idcommons.net/lists/arc/community/2009-08/msg00000.html
Identity of Indiscernibles, http://en.wikipedia.org/wiki/Identity_of_indiscernibles

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.

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>
        <Subject>...</Subject>
        <ds:KeyInfo>
           ...
        </ds:KeyInfo>
    </link>
</xrd>

Description

xrd/Subject : Type=URI. Subject Identifier or portion of Subject Identifier. CanonicalID in XRDS.

xrd/Subject/@set : (Option) Can specify “beginswith” to signify that the URI is only partial and beginswith the string.

xrd/Alias: Alias URI for the Subject.

xrd/KeyDescriptor: Wrapper element for ds:KeyInfo for the Subject.

xrd/KeyDescriptor/@use : Specify the usage of the KeyInfo, e.g., Signature, Encription, etc.

xrd/ds:Signature: Expresses the Signatory and the Signature over this XRD.

xrd/link: Shows the relationship that this Subject perceives against other subject.

xrd/link/Subjct: the Subject of the linked XRD.
xrd/link/ds:KeyInfo: has the public key of the Signatory of the Subject of the linked XRD. The linked XRD will be signed by the private key that corresponds to this public key, users can verify that the link is actually an inteded one.

Discussion Points

1. Do we really need KeyDescriptor?
2. Do we really need xrd/link/Subject? Would not xrd/link/uri suffice?