So, when the sun rises, it is the 10th IIW day.

I hoped to prepare more, but with the current ill-health, this probably is the most I could.

Here is the new version of OpenID Artifact Binding (AB) .

Repository: http://bitbucket.org/openid/ab/

Browser Friendly Cache: HERE

For those of you who do not know, OpenID/AB is a chartered Working Group at the OpenID Foundation, and aims to create another binding for OpenID, so that it is

1. More Secure so that it can go all the way up.
2. Browser URL length limit friendly.

In addition, we have been targeting to make it

1. Very easy to write libraries, only with standard libraries
2. Very easy to implement for RP. For lower assurance RPs, it should be just a matter of pasting a javascript snippet, and a link.
3. Highly scalable: Completely stateless so that it can scale

I think the goal has been achieved as of draft 06.

It is using OAuth2.0 as the base protocol, and is building identity layer on top of it. Unlike David’s OpenID Connect straw man, it is not overloading the access token of OAuth2.0, so we can use that as OAuth token even for this OpenID flow.

I have implemented it myself (not being a professional programmer, it took more time than it should - besides, it was the first time for me to write anything in Javascript, and how-do-I-debug it???) in couple of days, in Javascript and PHP.

The size of the code shows how easy it is.

OP (PHP): 251 lines including debug codes and comments, as well as HTML.
RP (PHP): 109 lines including debug codes and comments, as well as HTML.
Magic Signatures Library: 83 lines including documentation.
AES Encryption Library (wrapper): 30 lines.

So, in total, it is 373 lines including documentation and debug codes.

AND: it supports asymmetric signature for non-repudiation, completely stateless OP, and my (proprietary version of) attribute exchange.

You can test drive them here: TEST DRIVE

Nice thing about what I did here for the attribute exchange is that the relying party can ask what combination so ever that the RP wishes of any of the attributes supported by the user. It is just a matter of making a “Request Parameter File”, which looks like this.

{
“ns”:"http://specs.openid.net/auth/2.0″,
“mode”:"direct_checkid_setup”,
“client_id”:"http://rp.tonescape.net/”,
“claimed_id”:"http://specs.openid.net/auth/2.0/identifier_select”,
“identifier”:"http://specs.openid.net/auth/2.0/identifier_select”,
“redirect_url”:"https://openid4.us/rp/rp.php”,
“atype”:"openid2json+sig”,
“ns:ax”:"http://openid.net/srv/ax/1.0″,
“ax:mode”:"fetch_request”,
“ax:avatar”:"”,
“ax:nickname”:"”,
“ax:lastname”:"”,
“ax:firstname”:"”,
“ax:gender”:"”,
“ax:birthyear”:"”
}

By change the “ax:lastname” to “ax:lastname#ja_Hani_JP”, I can get her Kanji name as well. It is that simple.

Not only that, you can push the write the attributes as well.
Just change “fetch_request” to “store_request”, and provide values to the attributes.

I have not implemented the following features yet, but should not take too much time.

• immediate: it should add only a few lines of code…
• payload encryption: Now that the encryption lib is done, it should be simple

Perhaps you can help .

Based on the discussion this afternoon at iiw#7, here is my initial thoughts on the “policy/principle” and “criteria” that a VRM compliant service should fulfill. They actually are the underling abstract model of the proposed OpenID TX extension (now renamed to be something like CX, contract exchange), OpenID CX being a profile of it onto the OpenID framework.

Policy/principle:

• User owns his own data - he has full authority and control over them.

Criteria:

• User offers his own data to the vendors for a particular purpose on consent to meet his/her needs.
• Vender/Service must present a very specific data usage purpose clearly and must abide to it.
• Duration for the data usage and storage must be defined.
• User must be able to cancel the contract with an appropriate wind down time.
• User must be able to download all his data in a standard format from the vendor/service.
• User is able to delete his data at the vendor/service anytime he wishes except for the data the vendor is required to keep for legal compliance.
• Notification method should the violation to the contract term arise for each party must be defined.
• Restitution measures must be defined for the cases of inappropriate data usage and data leakage.

Tools^*1:

• All the above must be included in the relationship contract and mutually digitally signed with date.
• For long-term contracts, third party time stamping (digital signature with newer algorithms and date) must be done regularly to cope with algorithm compromise risk.
• All the data transfer/exchange must occur based on this contract.

In OpenID CX (formally TX), there will be a mutually digitally signed contract format defined with request-response protocol for creating it. All the subsequent data exchange will occur based on this contract. It would appear to me that the r-button state with joined sideway Us are nothing but the state that the above contract is in effect.

Note: An extremely long thread has started off from this message of mine to the ProjectVRM list. You may want to see them as well.

^*1 I have modified the original message a bit by separating out the Tools from the Criteria. Paul Madsen pointed out that it would be better not conflate Criteria with Tools and I fully agree. Thanks Paul!

Today, I have presented the concept of Trusted Data Exchange and Reputation Service at iiw2007b.

Am writing an article in iiw wiki, but submit succeeds only sporadically.

Had a problme with Linksafe login, so to create the article, I am using =sakimura which is being hosted at 2idi, but that is me, =nat. This seems to be the problem that was introduced in conjunction with the introduction of CardSpace as one of the authentication method.

Conversations:

with =eekim and =ovdavis: ref linking of inames crossing over the ibroker.

with Ashish Jain: Necessity of Reputation service for the distributed authentication and data exchange service to be useful, esp. on the RP reputation.

with Paul Trevithick: Higgins and the contract format.

with =wes of Authentrus (city of Osmio, ITU eTrust initiative, The World Trust Signatories Association):

Authentrus provide the remote enrollment technology (online, telephone, etc.)

Other notes from =wes: Use iname or OpenID as DN in X.509 certificate. On the importance of enrollment/registration. Certification/Registration/AuthN/AuthZ.

I have given a session on OpenID Japan success today.

See: