Log in

PAPE entering 60 Day Public Review

The OpenID Provider Authentication Policy Extension (PAPE) specification enables an OpenID Relying Party to request that the OpenID Provider satisfy a set of policies specified by the RP when the OP logs the user in. And it likewise enables the OP to reply to the RP saying which of the policies it satisfied.

The OpenID Foundation Working group on PAPE is now looking for comments from the community on the current Draft 7 of the SPEC .

The spec is extensible by communities who wish to add new Authentication policys and Assurance levels.

As the the first work product from the new OIDF specifications process, I am looking forward to getting this to a vote near the end of the year.


openID and DNS attacks

I found a site that helps RPs test there DNS for vulnerabilities.
It also explains some of the DNS attack details for those that want to know.


I was quite surprised today.

I got an email today from someone who read my first post and pointed out that I was referring to sec 15.4 not 15.2 of the openID 2.0 spec. The link was correct but the text was wrong. It is now fixed in the original post.

Thanks for finding that Nat.

I have the feature descriptions for OSIS I4 Interop openID listed at the OSIS site now. I still need to finish writing the tests.



XRI and the W3C

As you know the XRI 2.0 spec did not pass as a OASIS specification by one vote.

A number of the No voters indicated in there comments that they were voting no at the recommendation of the W3C. Some of these indicated that there intent was to encourage a dialog between the W3C TAG and the XRI-TC.

I would like to report that on Sep 3, a joint telecon between the TAG and the XRI-TC was conducted.

In the hour conversation not much was accomplished other than introductions and basic position statements.

In the TAG minutes of July 10 the call and progress were reviewed. http://lists.w3.org/Archives/Public/www-tag/2008Jul/0011.html

I encourage people to read the TAG minutes re XRI and other "Social Problems", leading people to create URI schemes.

David Booth from HP and I have had what I think is a productive exchange on the precise issue that concerns him and perhaps others on the TAG.


I think the point being discussed now though never raised by the W3C during the public comments period for the XRI 2.0 spec is as follows.

The XRI 2.0 spec defines XRI in four ways:
1. "XRI-Normal Form" with identifiers in the form =thread-safe (These are NFKC normalized UTF-8 strings)
2. "IRI-Normal Form" format in the form xri://=thread-safe (This is XRI Normal form escaped per Sec 2.3.2 of XRI syntax and xri:// prepended.)
3. "URI-Normal Form" in the form xri://=thread-safe ( IRI-Normal form transformed via Sec 3.1 of RFC 3987)
4. "HXRI Form" http scheme URL in the form https://xri.net/=thread-safe (URI normal form with xri: replaced by a htttp proxy resolver. http://xri.net/ in this example.)

A non normative draft refrence document on the transformations can be found at:

The HXRI form was created to address the concerns expressed by the W3C regarding backwards compatibility several years ago.

The problem as it may turn out is not that we have documented to little in the XRI 2.0 spec but perhaps too much.

We were under the impression that the information space is URI and worked with great diligence to fit into that.

It now appears that we were mistaken.

The W3C sees the http: scheme URL space as the universal information space.
This has lead to the conclusion that no new URI schemes should be registered.

We have done the work necessary to fit into the http URL scheme.

My question is should the OASIS XRI-TC remove references in the spec to the xri: scheme?
Is there anyone who wants xri: to be a registered URI scheme?

The spec would still need to explain all the transformations required to go from XRI-Normal to HXRI but could replace xri:// with something like, this-is-IRI-form-however-it-is-not-a-registered-iana-scheme-please-use-hxri-form-for-http: or something of the like to make processing easier inside applications.

If actively discouraging people from using the xri: scheme transform of an XRI makes people happy, I will personally take it as a proposal to the XRI-TC.

I suspect that there are other issues lurking that the TAG has yet to clearly articulate, however this is a start. If we can deal with this then perhaps we can resolve them all.


openID and DNS attacks

For some time I have been annoying people with my fixation on making certain both openID Providers and Relying parties take DNS seriously.

I point specifically to Sec 15.4 of the openID 2.0 spec.

Now most people don't read this far into the spec. Admittedly the spec authors also hedge on explaining the exact nature of the possible attack.

Today CERT has issued Vulnerability Note VU#800113, so now all the bad people now understand how to exploit potential DNS venerability's at openID Reliant parties, and how to use them to hijack openID accounts at those RPs.

I will point out that iNames are not effected by this if the RP is following the spec and using https or SAML resolution for XRI.

This relates to URL-based openID's such as http://ve7jtb.myopenid.com. If the openID provider is not using http redirects to send discovery to the https version of the url your account is vunerable to being hijacked at any openID relying party that is vulnerable to cache poisoning and other DNS attacks.

A simple way to test this is to type your openID directly into your browser bar http://ve7jtb.myopenid.com if you don't se yourself redirected to a https version of the URL, your OP is not doing all it should be to protect you.

You might say that when you enter openID that you enter something like ve7jtb.myopenid.com and expect that openID will automatically add the https:// for you. Well that would be an incorrect assumption. The openID 2.0 spec tells the RP to add http:// for backwards compatibility reasons, it is only if your OP redirects to the https version of your openID that https is used.

If you are only using your openID at sites for blog posts etc you may well not care.

One thing you can do is manually type https:// in front of your openID every time you log in.

The openID spec requires a RP to consider https://ve7jtb.myopenid.com a completely separate identifier from http://ve7jtb.myopenid.com.

If you have attached the http:// version to your account at a RP you would need to remove it or you will continue to be vulnerable.

On the Reliant Party (web site you are logging into) they MUST follow the spec and treat the two forms of the openID as two separate ID's and not automatically allow both to log in to the same account.

I am working on some feature tests for the upcoming OSIS I4 Interop

I will add that I have discussed this with openID providers who are not doing the https redirect over the past six months. Some have worrked to correct the problem others have not.

The results for library authors, openID providers, and openID Reliant parties who participate will all be publicly available. I like many of the authors of the openID libraries am doing this in my spare time, for the general good. So be patient as I get feature tests posted.

If people have suggestions for things that need testing please contact me and I will work with you to add them.

I am separately exploring using managed information cards for openID logins directly at Web Sites (RP), This will potentially be part of the Web services harmonization SIG at the Liberty Alliance.

My goal is to have a single login to a Web site that provides infocard, openID, and ID-WSF credentials. I think the potential simplification of the user experience could have significant benefits. However getting all three SSO camps together is not an overnight thing:)


Totally gratuitous view from my house today.


Swallowtail Closeup

Hawk in Flight

Hawk in Flight
Originally uploaded by HDR Cafe

Hawk with fish

XRI and information spaces

Of late I have been reading the W3C TAG mailing list.

Given recent events, my intrest in gaining some insight into the W3C's thought process regarding opposing XRI/XRDS should not come as any particular surprise to people.

The other day I cane across a post on the list by Mark Baker http://www.markbaker.ca/ that I thought was quite insightful.

I quote it below for reference.

Prior to the Web, we had an abundance of information spaces, one for
pretty much every area of work, study, etc.. you could identify.
Another name for these spaces was "silos". What the Web did, was
provide an "information space of information spaces", allowing these
silos to plug in to a unified space whereby they could exchange
information with other silos... which of course means that they were
no longer silos.

URI scheme proliferation is not the problem here IMO, just a symptom
of the real problem: information space proliferation. If you can
avoid creating a new information space, you should, no matter what
identifier syntax you're using.


I think this perhaps goes to the heart of the matter.

I used the internet before http, I remember my awe at seeing NCSA Mosaic for the first time.

The heart of the XRI/XDI work is to open up information silos to the Web not create new ones.

XRI's in conjunction with XDI data servers are intended to provide a gateway from SQL and other silo information stores.

The goal is to create a globally addressable database infrastructure with fine grained authentication and access control down to the field level.

This includes remote joins and multiphase commits in XDI.

We developed HXRI a format recommended to us by the W3C so that http clients could access XRI resources through http gateways.

Is this parallel development to SPARQL, you may ask.

The answer to that is yes and no. XRI/XDI does overlap with SPARQL use cases, however it goes beyond them to address issues of gatewaying to SQL and other systems with both read and write functionality.
The distributed write functionality was the hardest. Something declared out of scope in SPARQL.

This is not in any way a criticism of SPARQL my company ooTao is considering adding a read only SPARQL interface to our XDI server.

I think it is true that both groups are working towards similar goals though our methods may differ on some points.

It would have been a tragedy if innovation on the internet had stopped at Gopher, I commend Tim and others for there innovation of new standards.

However I must defend my and others right to innovate, in the same manner that the members of the W3C were allowed to.
Remember there wasn't always just one version of html, thats in large part why the W3C created.

I personally think that our approach to creating a "data web" is compatible with the W3C notion of a "semantic web".
I hope we can come together on this in some way or at least agree to differ on the best approach.

People have asked me about the technical issues around XRI and the W3C's concerns.

I think the larger political and philosophical issues need to be addressed first so that we can constructively work together an any technical issues that may or may not exist.

Again I thank Mark for his clarity on the issue.