I had a very good discussion this morning at OASIS Open XRI TC F2F Day 2.

I came up with the XRD SimpleSign Proposal - Three options on Certificate URI locations to chose from, and we discussed pros and cons of those options and came up with a fairly robust result.

See: http://wiki.oasis-open.org/xri/XrdOne/SimpleSign

The key here is to utilize X.509 v.2 field “SubjectUniqueIdentifier” to store CanonicalID into it.
By doing so, the XRD and the certificate is tightly coupled without the need to follow the resolution chain as it has been in XRI Resolution 2.0.

Thus, this XRD can trivially prove that it is authoritative for the entity with the CanonicalID (SubjectUniqueIdentifier), and can serve Public Key Cert: i.e., can be used for Public Key Discovery. Also, this XRD will describe what service this entity offers, or with what service this entity has preferred relationship with.

IMHO, it is a very powerful tool, and I am so excited with it.
It can add a security layer that OpenID et al. needed so badly.

It might change the world, at least in a small way

:hammer:

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: