Here is what I got:

Reputation

A Reputation is a Reputor’s assessment of a Subject on a Criteria.

Reputor

A Reputor is a third party that assess the likelihood of the Subject fulfilling the Criteria. A Reputor may be composed of 1 to N assessers.

Reputation Score

A Reputation Score of a Subject on a Criteria by a Reputor is the subjective probability assigned by a Reputor that the Subject fulfils the Criteria.

What do you think?

Started to think that “Reputation” is a word that is too broad for most people. Probably better to concentrate on the more concrete cases.

The cases I am interested are specifically:

1) Probability of the PAPE assertion being true.
2) Probability of the adhearance of the RP to the usage proposal of the personal data that I provide.

In the above cases, I started to feel that just stating

a) Criteria, i.e., 1) or 2) above
b) Subjective Probability: 0 to 100 numeric percentatge.
c) Variance/Confidence range

together with other things like signature etc. for the security reasons are enough.

Unfortunately, it only accepts OpenID provided by:

- OpenID.ne.jp
- Yahoo! JAPAN
- livedoor
- hatena
- JugemKey

Why do those services do white listings?

Does it add value? NO. All these are free services, and you can make any number of OpenID with these providers. Then, why bother whitelisting to them?

Clearly, whitelisting does not go with the original philosophy of OpenID.

I hope that this “white listing” boom will find its end soon.

But for it, I guess we need some workable reputation framework…

From Left to Right:

=nat, Robert Ott (OpenID Switzerland^*), David Reindl (OpenID Switzerland), Martin Paljak (OpenID Estonia), Snorri Giorgetti (OpenID France, OpenID Europe, Chaiman).

It was a six course dinner.
Drink started with Clemont(?) de Alsace, a Swiss white wine, which I do not remember the name, then Mouton Cadet.

* Yet to be formed.

45 reporters from 37 magazines and news papers showed up for the press conference and numerous articles were published on it, that it made into the top page of the Google News with a photo.

As of now, over 27 articles were written at various places.

The REAL ID Act of 2005 is said by some to pave the way for a United States National ID Card and has come under heavy criticism from a wide range of people in the US. Some recent developments indicate that a National ID card could be tied to the federated authentication standard called OpenID.

At the most basic level, this would mean that you could sign in with your National ID card to all the websites where today you can login with a Yahoo! or AIM or other OpenID. Hmmm…

Are National ID Cards Going to Snuggle Up With OpenID?

IMHO, the government forcing the use of the Veronym and centralized government operated OpenID is a bad thing.

However, if it is a pseudonym which is hosted in various places and given out separately to each RPs with some assertion on the identity’s attribute, such as age, is not so bad. You will be able to get the service that you deserve, and you still do not get to be correlated at the RPs.

Of course, this OP may be able to determine your Real Identity, but that is depending on the operation principle of the OP. It might just use the National ID for the registration and discard the National ID itself right after that.

In fact, coupling of OpenID with this kind of government or otherwise authoritative certification document for the registration purpose serves to enhance privacy. You can prove some of your attribute and still you are anonymous. This has not been possible hitherto.

Thus, I would argue that coupling of National ID type of thing and OpenID is privacy enhancing.

Remember, Certification, Registration, Authentication, Authentication Assertion, Authorization is all different things. It is awfully wrong to use the certificate (such as National ID) as the authentication identity, but, for registration purposes, it is quite useful.

http://www.readwriteweb.com/cgi-bin/mt/mt-comments.cgi

does not support OpenID 2.0 nor XRI so that I cannot login to comment…
It does not even support the https://… url.

It is posing an interesting question.

As it so happens, Bill (the Executive Director of OpenID Foundation, OIDF), states that “Although the foundation will continue recruiting companies of all sizes to support the OpenID standard, it is not likely to add any more board members.”

It seems the rationale behind it is that community and the corporate power has to be balanced as Dick Hardt states:

The community board members want to ensure that the Foundation represents the community, so would like to limit the Corporate board membership, or at least ensure that community board seats balance the corporate board seats – so adding additional corporate board members is not out of the question, it would require careful consideration by the board.

That is fair enough, but this prompted me of another question.

When it comes to balance, is it balanced at all to start with?

Community board is OK. It is re-electable. On the other hand, Coproate board is not. And the list:

Google, IBM, Microsoft, Verisign, Yahoo!

is 100% U.S.A.

Number of the seats in the board is as follows:

Community: 8
Corporate: 5

So, the U.S.A. is granted at least 5 / (5+8) = 38% vote permanently no matter what.

Since some of the voting requires supermajority of the board, it effectively means that the U.S. has veto to these items.

As it stands, OpenID Foundation cannot escape the criticism that it is a U.S. local organization, unfortunately. I guess OIDF needs to fix this before this “label” proliferates.

IPR
- IPR overview
- Why the IPR policy and process
- IPR Non-Assertion Agreements for Entities and Individuals (covers
through OpenID 2.0)
- IPR Policy and Process (for new spec working groups)
- Executed IPR Non-Assertion Agreements (not all from the corporate
board members have been uploaded yet) -

Foundation
- Articles of Incorporation with the state of Oregon (http://openid.net/pipermail/board/2007-May/000274.html)
- Basic policies and procedures -
- Board Meeting Minutes
- Membership agreement

DOWNLOAD
========
http://www.sakimura.org/modules/mydownloads/visit.php?cid=1&lid=8

INSTALL
=======

1. Unarchive the files under modules/ directory.
2. Define XOOPS_TRUST_PATH somewhere out of the web accessible path
   in mainfile.php
3. Create a foloder “_php_consumer” under XOOPS_TRUST_PATH and
   change the permission so that it will be writable by the web server.
4. Install the module like other modules.
   (For XoopsCube, install the block as well.)
5. Give access permission to guest group for this module.
6. Install block for all the modules.

TODOs
=====

1. Create Admin Panel for easy maintenance of the OpenIDs.
2. Make 5 and 6 above automagic.
3. Clean up the code
4. Replace Dummy Admin screens to real ones.
5. Test on PHP 4.x. It has been only tested on PHP 5.2
　 Let me know if someone try on 4.x.
6. Make sreg parameters specifiable through admin screen.
7. sreg policy.
8. PAPE

1. Reputation needs to have an identifier of somebody being scored.
2. The same for who is scoring.
3. For what criteria, this reputation score was made.
4. For the reputation to be aggregatable, it has to have a distribution that we know about the aggregated distribution (such as normal distribution).
5. The information about the distribution, including what distribution, mean, and standard diviation must be published together with the score.
6. Display score must be intuitive for an average person.
7. Date that score was made
8. Signature by the score maker

So, the reputation score file should contain:

In the above table, I am proposing to use cumulative distribution P(X<x) as the display score, so that the meaning of the score is clear for anybody. If the score is 95.5, the subject is among the top 5% of most trusted in that criteria.

Also, public key of the subject being rated is included as par OpenID TX proposal.

Using this, parties who are trying to talk to the subject can be sure that the party really is the party that has been rated by the above rating agency.

This data can be serialized in XML format, or JSON, or tag=value format etc.

OK. This is another input to forthcoming ORMS TC at OASIS Open.

As it so happens, in OpenID 2.0, RP after resolving the OP address, requests OP to establish the association by Diffie-Helman. The association needs to be stored at both OP and RP. Also, because of this phase, check_authentication phase is also required.

Perhaps this was necessary in the days of OpenID 1.0, but I feel it to be rather redundant now.

If OP and RP publishes their Public Key in their XRDS, we do not need Association nor check_authentication, I think, simplifying the protocol further, and strengethning the security further with Reputation Service that we are proposing.

Perhaps, it could be an option for OpenID 3.0 kind of thing…

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. “Quiet Enjoyment” chpater 40. P.479: Why PKI has not work? PKI is just construction materials. Useless unless was turned into a house.

etc.

Hopefully, I can present it at iiw2007b.

Panel Discussion in Japan oftern ends up just as a series of presentation, but this time, it was a real panel discussion, which was good.

At the end of the Panel discussion, Mr. Takahashi asked the panelers “What is Digital Identity?”. I was the third person to talk about and by the time it reached me, pretty much was spoken. So, I said “It is a technology that brings Power to the People. ” refering to the notion of “Theirdentity, Ourdentity, Mydentity”. The last one to speak was Mr. Shitamichi of Sun Micro. He said,

“It is Love.”

Well, this needs some explanation in English, I guess. “Love” in Japanese is pronounced “I”: yes, the first letter of “Identity”.

See http://www.hatena.ne.jp/info/openid for the further details.

As an OP, it provides OpenID in the form of

http://www.hatena.ne.jp/hatena_user_name/

As an RP, it only supports the following OpenID providers.

livedoor
LiveJournal
TypeKey
Vox

As the result, I cannot use their service with my OpenID. This is rather unfortunate.

Whether it is OP or RP, unless we ready the reputation service that measures the trustability of the services quickly, the openess of the OpenID gets hart. Need to sort this out.

Going over the PAPE spec this morning, however, I did not find too much about RA activities. NIST SP800-63 Level 2 and upwards requires identity proofing, but from the PAPE spec, it is not clear if these are required.

Specifically, for openid.pape.nist_auth_level, the spec states “[NIST_SP800-63] corresponding to the authentication method and policies employed by the OP when authenticating the End User”.

The examples following the above statement also talks only about the authentication and not registration. As such, I felt that some OPs advertising openid.pape.nist_auth_level would be talking only about “authentication” and not about “registration”. Maybe that is the intention of the Spec. If it is not, then I feel that it needs to state about the identity proofing methods as well somewhere in the spec.

Then, even if the identity proofing (RA) activities are included, I kind of feel that being able to state just the NIST level would be a bit limiting. Especially for the financial applications, there may be country specific guidelines and it would probably be better to be able to state the compliance level with that standard or legislation.

e.g., instead of just having openid.pape.nist_auth_level, having something like this may do…

openid.pape.conf_std=http://www.fsa.go.jp/guideline/online-auth.html
openid.pape.conf_level=3

(Note: above url is bogus. Also, since these URIs are not persistent, it might just better to state a token like jp_fsa_online_auth and have reference table elsewhere. ) In this manner, NIST level would be described as

openid.pape.conf_std=http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf
openid.pape.conf_level=2

Then, again, to be generic on the legislations/guidelines, it might just be better to provide the raw information. This leads me to consider AQE, which can explicitly state enrollment/registration properties and authentication properties, instead of PAPE again. We cannot expect OP to cover every legislation and guidelines. There are going to be numerous guidelines defined in each verticals and states/counters. This leads me to think that it is the RP’s responsibility to map the raw info to the applicable guideline/law as the vertical application. (I guess SAML was constructed like this because it had a lot of international and industrial representation. ) What would you think?

I am pretty sure that there are rough edges, but please have a try and let me know those.

Unfortunately, current server that I use is not too stable so there might be the times that you need to retry 5 min. or so later but … (I think this is the effect of Xen. I do not know how to fix it…)