Thread-Safe

(Untitled) [Flickr]

2010-08-26T10:43:28-07:00

ve7jtb posted a photo:

(Untitled) [Flickr]

2010-08-26T10:43:03-07:00

ve7jtb posted a photo:

(Untitled) [Flickr]

2010-08-26T10:42:38-07:00

ve7jtb posted a photo:

(Untitled) [Flickr]

2010-08-26T10:41:32-07:00

ve7jtb posted a photo:

Links for 2010-08-25 [del.icio.us]

2010-08-26T00:00:00-07:00

SAML 2.0 Debugger

Links for 2010-08-17 [del.icio.us]

2010-08-18T00:00:00-07:00

Study Reveals 75 Percent of Individuals Use Same Password for Social Networking and Email | Information Security News - SecurityWeek: IT Security News & Expert Insights

Links for 2010-07-31 [del.icio.us]

2010-08-01T00:00:00-07:00

RegisterProtocolHandler Enhancing the Federated Web « Mozilla Webdev

Links for 2010-07-06 [del.icio.us]

2010-07-07T00:00:00-07:00

New opportunities for linked data nose-following - W3C Blog

Links for 2010-07-01 [del.icio.us]

2010-07-02T00:00:00-07:00

(Untitled) [Flickr]

2010-06-28T16:51:05-07:00

ve7jtb posted a photo:

Links for 2010-05-16 [del.icio.us]

2010-05-17T00:00:00-07:00

Links for 2010-05-10 [del.icio.us]

2010-05-11T00:00:00-07:00

Access granted: NIH opens doors to medical resources -- Federal Computer Week

Open Identity Pilot announced for US Government

2009-09-09T14:11:00Z

The project I have been working on for the last 6 months is no longer a secret.

Secret Government Project

Today the OpenID Foundation, Information Card Foundation, and the US General Services Administation (GSA) are announcing the pilot proram for US gov sites accepting Information Cards, openID, and SAML.

InCommon has been working with the GSA and NIH for a while now so may be less news worthy, but they are no less a participant.

We have ten Identity Providers who are announcing today there participation in the pilot, and there intention to follow through with certification by one of the "Trust Framework Providers".

GSA Pilot information
Infocard Pilot information
OpenID Pilot information

Chris Messina post

The GSA Information card profile is in the final approval process.
The GSA OpenID profile was approved and released today.

I have been working closely with the Identity providers and the initial government RPs.

Testing has been going on for a while on Test-ID where there are example endpoints for IdP to test against.

Participation for Identity Providers is not limited to the ten announced today.

The Foundations will be accepting applications from interested IdP from around the world.
For those of us who arn't American the US Government is not restricting this to only US IdP.

Government agencies colaberate internationaly. The NIH is very interested in supporting people from around the world having access to it's resources.

I expect that we will see European and other IdP joining the program shortly.

I have also had conversations with other governments from around the world who are very intrested in this model. I expect some of them to develop there own trust frameworks for access to there resources as well.

I am hoping this is a turning point for the adoption of all federated identiy technology.

John B.

GSA opens up to open Identity

2009-08-10T21:03:18Z

The GSA held a privacy conference in DC today to discuss the work it has been doing with the OpenID Foundation, Infocard Foundation and INCommon.

The intention is to open government web sites and services to identities provided by commercial providers using open technology.

The test-id.org site has a number of tests for the new profiles for Information Cards and openID.

The OIDF and ICF released a paper on open trust frameworks today.

Identity providers who are interested in participating in the program should contact the respective foundations for more information.

People interested can read the Trust Provider Adoption Process

I am hoping that GSA/ICAM releases the profiles soon so that we can have a full discussion.

John B.

Directed Identity vs Identifier Select

2009-08-01T21:26:05Z

Will Norris has a good post on the difference between Directed Identity and Identifier Select.

I expect more OP's to be supporting pairwise identifiers later this year.

Updates on this in the September timeframe.

John B.

Ruby openID 2.0 library

2009-04-18T01:37:45Z

JanRain posted an update to there popular openID 2.0 library for Ruby today.

I strongly recommend that anyone using this library update to the latest version as soon as possible.

The page to download the latest version is:

http://openidenabled.com/ruby-openid/

John Bradley

New draft of the IMI spec for your enjoyment.

2009-01-13T21:57:14Z

The document named identity-1.0-spec-ed-04.pdf
(identity-1.0-spec-ed-04.pdf) has been submitted by Dr. Michael Jones to
the OASIS Identity Metasystem Interoperability (IMI) TC document
repository.

Document Description:
This document is intended for developers and architects who wish to design
identity systems and applications that interoperate using the Identity
Metasystem Interoperability specification.

An Identity Selector and the associated identity system components allow
users to manage their Digital Identities from different Identity Providers,
and employ them in various contexts to access online services. In this
specification, identities are represented to users as Information Cards.
Information Cards can be used both at applications hosted on Web sites
accessed through Web browsers and rich client applications directly
employing Web services.

This specification also provides a related mechanism to describe
security-verifiable identity for endpoints by leveraging extensibility of
the WS-Addressing specification. This is achieved via XML [XML 1.0]
elements for identity provided as part of WS-Addressing Endpoint
References. This mechanism enables messaging systems to support multiple
trust models across networks that include processing nodes such as endpoint
managers, firewalls, and gateways in a transport-neutral manner.

View Document Details:
http://www.oasis-open.org/committees/document.php?document_id=30663

Download Document:
http://www.oasis-open.org/committees/download.php/30663/identity-1.0-spec-ed-04.pdf

PLEASE NOTE: If the above links do not work for you, your email application
may be breaking the link into two pieces. You may be able to copy and paste
the entire link address into the address field of your web browser.

-OASIS Open Administration

openID Board Results

2008-12-30T00:00:49Z

I want to congratulate the new board.

I look forward to working with you.

http://openid.net/2008/12/

John Bradley

PAPE 60 Day Public Review ending Dec 21st

2008-12-20T14:07:42Z

A reminder to all those interested in PAPE to get there coments back to the Working Group by Dec 21.

If no changes are required from the comments we receve the voting for PAPE should start next week.

=jbradley

The OpenID Provider Authentication Policy Extension (PAPE) Working Group recommends approval of PAPE Draft 7 as an OpenID Specification. The draft is available at these locations:

http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-07.html

http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-07.txt

This note starts the 60 day public review period for the specification draft in accordance with the OpenID Foundation IPR policies and procedures. This review period will end on Sunday, December 21st. Unless issues are identified during the review that the working group believes must be addressed by revising the draft, this review period will be followed by a seven day voting period during which OpenID Foundation members will vote on whether to approve this draft as an OpenID Specification.

As background, the proposal to create the working group, which the membership approved, is available at http://openid.net/pipermail/specs/2008-May/002323.html. The specifications council report on the creation of the working group is available at http://openid.net/pipermail/specs/2008-May/002326.html.

Cooler XRI

2008-10-24T11:37:49Z

Not that XRI themselves are not cool in the conventional sense. Well as cool as an OASIS TC can make them.

What I am refering to is a property of XRI that has been there all along but we are now seeing in a new light thanks to our cooperative efforts with the W3C TAG.

The W3C has created a document Cool URIs for the Semantic Web

In yet another case of great minds thinking alike: XRIs in the form of HXRI meet all the qualifications of "Cool URI" if we change from a 302 redirect to a 303 redirect.

Givein that there is no reason for us not to change the redirect type based on the TAGs advice , we are getting closer to a common understanding.

We all now understand that:

* If an "http" resource responds to a GET request with a 2xx response, then the resource identified by that URI is an information resource;
* If an "http" resource responds to a GET request with a 303 (See Other) response, then the resource identified by that URI could be any resource;
* If an "http" resource responds to a GET request with a 4xx (error) response, then the nature of the resource is unknown.

Givin this understanding the "Cool URI" document shows us how to construct URI for "real-world objects or things".

As it happens every XRI is also about a "thing". We have attempted to come up with better language than "thing".

I quite like the description used by Stuart Williams of "Platonic ideal" in that when I the XRI =jbradley to refer to me I am not literally refering to me but to an ideal of me that can be descibed by meta-data in the same way that a mathmatician describes a circle via a formula.
Both myself and any phisical circle are crude appoximations of the ideal.

Givin that the XRI =jbradley names the PI(Platonic ideal) me how do I use that as a URI?

I can use the proposed sub scheme for a http: XRI and put the relative XRI on a base http: URI:

http://xri.net/=jbradley

Now if this URI returns a 303 and link header information about where to retreve meta data about =jbradley and perhaps alternate resources relating to =jbradley based on content negotiation it is by the W3C's definition a cool URI.

The cooler part is that we now have the XRI shared semantics that can be applied to any XRI subsceme URI to describe =jbradley.

This is achieved through a mechanism simmilar to the one that the W3C recommends near the end of "Cool URI". They cite D2R Server as an example of using SPARQL and 303 redirects to serve RDF documents about "Platonic ideals".

XRI has and is proposing to do the same thing with some diffrences:
1. Using XRDS instead of RDF documents. (Yes we may add a RDF format for XRI meta-data)
2. Using a global scope for XRI like ARK
3. Using a http sub scheme to define the shared semantics per David Booth's recomendations
4. Use multiple schemes as base URI for the same XRI for shared semantics i.e. http: and https:

I am hoping we can now make rapid progress on resolving our differences with the TAG to remove there objections to XRI.

=jbradley

PAPE entering 60 Day Public Review

2008-10-23T11:52:48Z

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.

=jbradley

openID and DNS attacks

2008-07-28T15:08:22Z

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.

http://www.doxpara.com/

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.

=jbradley

XRI and the W3C

2008-07-14T16:38:03Z

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.

http://lists.w3.org/Archives/Public/www-tag/2008Jul/0012.html
http://lists.w3.org/Archives/Public/www-tag/2008Jul/0015.html
http://lists.w3.org/Archives/Public/www-tag/2008Jul/0014.html
http://lists.w3.org/Archives/Public/www-tag/2008Jul/0019.html
http://lists.w3.org/Archives/Public/www-tag/2008Jul/0021.html

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:
http://wiki.oasis-open.org/xri/XriThree/FormsAndTransformations.

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.

=jbradley

openID and DNS attacks

2008-07-11T17:51:13Z

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:)

Regards
=jbradley

Totally gratuitous view from my house today.

Swallowtail Closeup

2008-06-28T19:15:21Z

Swallowtail Closeup
Originally uploaded by HDR Cafe

Butterfly at Cultus

2008-06-28T19:13:24Z

Better Butterfly Bokeh!
Originally uploaded by HDR Cafe

Hawk in Flight

2008-06-28T19:09:07Z

Hawk in Flight
Originally uploaded by HDR Cafe

Hawk with fish

2008-06-28T19:05:47Z

Ducks in front of my house

2008-06-27T06:54:05Z

XRI and information spaces

2008-06-07T22:52:29Z

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.

Mark.
-------------------------------------------------------------------------------------

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.

Regards
=jbradley

XRI 2.0 Vote 74% positive!

2008-06-01T18:16:18Z

I want to start by thanking the 73 OASIS voting members who voted fort the XRI 2.0 spec I know there were others who wanted to vote in favor but couldn't get there votes cast in time due to there organizations voting reps being unavailable.

There were others who supported us but did not vote due to a company policy to not vote on specs they are not directly involved in.

I especially appreciate the votes from the Liberty Alliance, AOL, Boeing, Oracle, Novell, Nortel, Intel, EMC, Corel and the US Department of Defense to name a small number of our supporters.

The vote had close to a record 33% turn out with only two other votes in OASIS getting higher turnouts.

We did so well it is unfortunate that we lost the vote.

Yes according to OASIS rules we needed a 75% + 1 supermajority to pass.

We missed the mark by one no vote.

Perhaps there is room for compromise with the W3C though negotiating from our current position with a group who is fundamentally opposed to our existence can be a bit of a challenge.

It remains to be seen how well the small companies that comprise the majority XRI-TC can continue this fight that has become more political than technical.

XRI will not disappear. The question that will be asked, is why should we put in the effort to go through a standards body like OASIS, when other organizations like OpenID, oAuth and the like don't .
I have to this point believed that there is value in the peer review process.

However that didn't happen in this case. Certain groups saved there criticism and comments until the XRI-TC's hands were tied by the process itself. We did make changes as a result of the review process.
After that process is done the TC can not modify the spec in any way. There is no way to make a non normative text change as some suggested.

This no vote sends us back to the start of the OASIS process. We need a new draft spec that the committee must approve etc. At the fastest possible pace we are looking at 6 months to bring it back for a vote.

I must say that the XRI 2.0 spec still stands as committee spec and continues to be referencible.
Many OASIS committee specs are never put to a full vote, so the XRI 2.0 will continue to live on as a committee spec.

I will keep people updated on any progress or contact that is made with the W3C, and plans for XRI 2.1.

Regards
=jbradley

W3C TAG and OASIS open Call

2008-05-30T17:36:49Z

I would like to retract any apology I may have made to Tim Berners-Lee or the W3C TAG.

It is now clear from your actions, actively lobbying OASIS members to oppose the XRI 2.0 spec that the registration of the xri:// scheme was a red herring.

It is truly unfortunate that the TAG members choose to spend there time trying to influence democratic standards body's on topics that they themselves according to their public minutes have not discussed the XRI-TCs response to there questions during the public review.

I believe that the W3Cs position on this is wrong, and they would realize that if they took the time to talk to the XRI-TC.

The OASIS XRI-TC has arranged for a open conference line to open and monitored by the TC members (Me) all day.

If any OASIS or W3C TAG member is interested in having a constructive discussion regarding the vote, feel free to phone, email or message me (skype://ve7jtb) for the conference bridge number.

The vote closes Saturday night and will likly be the largest turnout in OASIS history.

I will enjoy getting back to real work.

=jbradley

The case of the XRI scheme

2008-05-26T17:17:39Z

I confess.

It's perhaps my fault.

There is a lot of talk at the moment about the XRI spec and if our lack of registering the URI scheme with IANA indicates our intent to subvert or circumvent URIs.

The simple answer is NO! That is not has not, and never will be our intent on the XRI-TC.

There were legitimate issues raised by the W3C regarding the XRI 1.0 spec. Those changes needed so that XRI could be regesterd as a URI scheme along with support for oAuth and better intigration with openID were made to XRI 2.0.

The OASIS process is a slow one. This involves public and peer review.

We thought we had the spec finalized late last year.

I was tasked to begin the scheme registration process at the IANA. However OASIS informed us that as the review process wasn't final I should hold off on the registration so that the final spec could be referenced in the application.

However during the public review as the result of feed back from the oAuth people we incorporated some of there feedback ot make the spec more useful to them.

That is how the OASIS process is supposed to work. This however set our timetable for full OASIS approval back almost three months.

As a result of the XRI 2.0 spec still being in the balloting process I have yet to begin the registration at IANA. This is till on my to do list.

Some people including Sir Tim Berners-Lee and the W3C TAG, perhaps see this as a plot. However everyone involved in official standards processes understands the complexity of, coordinating all the moving parts.

It was not my intent nor that of any member of the XRI-TC to disrespect the W3C TAG in any way.

Hopefully in future the people from the TAG will feel free to contact myself or other members of the XRI-TC directly, with any concerns.

The XRI-TC has posted an official response to the W3C TAGs recommendation against the XRI 2.0 spec at: http://wiki.oasis-open.org/xri/XriSolvesRealProblems

I hope that people are still supporting the spec, despite this confusion with the W3C.

=jbradley

OpenID Phishing

2008-05-26T15:31:31Z

I met with the guys at fun.de last week when I sas in Redmond.

At http://OpenIDbyCard.com/ they have a way of acting as a proxy for a self issued info-Card to be used as a login at a openID Reliant party, like Plaxo.

It is a interesting proof of concept. I encourage people to try it.

However remember that the claimed_ID of the openID login is a hash generated from that selfissued cards ppid at http://OpenIDbyCard.com/ hashed with the realm of the openID RP.

What that means is that if anything happens to the card the identity is gone forever. Also if you move the card to another computer the identity changes. Just a caution, you may just want to use it for testing at this point.

The other approach that we are using at Linksafe.name is to bind a self issued card to your openID login at the OP. This provides the benefits of a traditional OpenID with the Phishing resistance of an info-card login.

If you loose the info-card or change computers you can associate a new self-issued card with your openID account.

I am the first to admit that these are only half steps to a more ideal Phishing resistance, and usability marriage between openID and info-cards.

The guys at fun.de have a good demo of how easy it is to Phish openIDs at http://idtheft.fun.de/
Warning this will Phish your OpenID password!!! That however is the point they are making.
Note this is only one of the possible attacks, depending on how your OP is set up.

If you aren't feeling brave Mike Jones steps though the site on his blog http://self-issued.info/?p=73

I am looking forward to working with fun.de and others interested in creating a better openID info-card that can be used to directly login to a RP and assert a verifiable OpenID to initiate service discovery for oAuth and ID-WSF.

More on that as I move the project along.

=jbradley

XRDS discovery in Open Social

2008-05-25T19:40:26Z

This is taken from the openID list.

It is gratifying to see how people are starting to use XRDS for service discovery.

Remember that XRDS discovery works almost as well with URLs and XRDS simple as it does with XRI and full XRDS.

This example from Google is stll in the oAuth context, however as people get used to the concept I hope to see more use people's openID XRDS documents to describe the services that people have associated with there identity.

It has always been our goal in the XRI-TC to encourage OPs to use the XRDS to describe where the oAuth endpoint for services like photo sharing etc are, so that the RP can discover the information dynamicly.

=jbradley

Message: 2
Date: Sun, 25 May 2008 11:44:52 -0700
From: John Panzer
Subject: Re: [OpenID] XRDS RP discovery when dynamic pages allow
logins?

My use case is here:
https://docs.google.com/a/google.com/Doc?docid=dc43mmng_2g6k9qzfb&hl=en

5. Discovery

A container declares what collection and features it supports, and
provides templates for discovering them, via a simple discovery
document. A client starts the discovery process at the container's
identifier URI (e.g., example.org). The full flow is available at
http://xrds-simple.net/core/1.0/; in a nutshell:

1. Client GETs {container-url} with Accept: application/xrds+xml
2. Container responds with either an X-XRDS-Location: header
pointing to the discovery document, or the document itself.
3. If the client received an X-XRDS-Location: header, follow it
to get the discovery document.

The discovery document is an XML file in the same format used for
OpenID and OAuth discovery, defined at
http://xrds-simple.net/core/1.0/:



       <XRDS xmlns="xri://$xrds">
           <XRD xmlns:simple="http://xrds-simple.net/core/1.0" xmlns="xri://$XRD*($v*2.0)" xmlns:os="http://ns.opensocial.org/" version="2.0">
               <Type>xri://$xrds*simple</type>
               <Service>
                 <Type>http://ns.opensocial.org/people/0.8</type>
                 <os:URI-Template>http://api.example.org/people/{guid}/{selector}{-prefix|/|pid}</uri-template>
               </Service>
               <Service>
                 <Type>http://ns.opensocial.org/activities/0.8</type>
                 <os:URI-Template>http://api.example.org/activities/{guid}/{selector}</uri-template>
               </Service>
               <Service>
                 <Type>http://ns.opensocial.org/appdata/0.8</type>
                 <os:URI-Template>http://api.example.org/appdata/{guid}/{selector}</uri-template>
               </Service>
           </XRD>
       </XRDS>

Each Service advertises a service provided by the container. Each
container MUST support the service Types documented below and MAY
support others by advertising them in the discovery document. Each
service comprises a set of resources defined by the given URI
Template (or URI, if there is only a single resource). Clients
follow the URIs and instantiate the templates to find and operate on
specific resources. (URI Template syntax is documented at
http://www.ietf.org/internet-drafts/draft-gregorio-uritemplate-03.txt.)

The set of substitution variables is fixed for each service Type.
The core set of service Types and their substitution variables is
documented below. Extensions to OpenSocial SHOULD document their
substitution variables; note that a reasonable place to put human
readable documentation is at the namespace URI.

OpenID 2.0 unsolicited responses and Directed Identity.

2008-03-14T20:54:04Z

In openID 1.0 there was a clear relationship between the input identifier and the resulting authentication.

If I delegate my openID to Linksafe eg:
I include in the html returned by a GET on httpL//thread-safe.net

If I log in and get a positive assertion I have proved the claim that I control the URL http://thread-safe.net.

In OpenID 2.0 things change sometimes:)

If I do the same thing with openID 2.0

The OP might do exactly the same thing in exactly the same way.

Going to the OP openid.claimed_id="http://thread-safe.net" and openid.identity="=thread-safe"

The OP could return both unchanged with a positive assertion. This results in the same proof we had in openID 1.0.

The OP may however choose to alter the openid.claimed_id and could return something like openid.claimed_id="https://linksafe.name/=thread-safe"

Changing the openid.claimed_id is something Yahoo for example is doing with there OP. The RP preforms discovery on the new openid.claimed_id and if the OP is authoritative for the URL according to the rules, the RP must ether use the new openid.claimed_id or reject the login.

In the case where the person is coming directly from there OP without first being redirected from the RP (Unsolicited positive assertion, Sec 11.2), there is no Input identifier that the RP knows about.

In the case where directed identity is requested by the RP by sending openid.identity="http://specs.openid.net/auth/2.0/identifier_select", the RP should be smart enough to know that the input identifier has nothing to do with the verified resource and should not be used for any purpose.

The question is what to do in the case of a solicited response.

Consider something like the Yahoo case. There endpoint ignores the incoming openid.identity and asks me to login to my, or anyones yahoo account for that matter.

The RP sends openid.claimed_id="http://thread-safe.net" and openid.identity="https://me.yahoo.com/ve7jtb"

If I choose https://me.yahoo.com/ve7jtb as my Yahoo openID, yahoo sends a positive assertion for openid.claimed_id="http://thread-safe.net/" and openid.identity="https://me.yahoo.com/ve7jtb".

The RP accepts it like any delegation and my primary key at the RP is http://thread-safe.net/

Consider now if I log into yahoo as jbradley and select https://me.yahoo.com/jbradley as my openID

openid.claimed_id="http://thread-safe.net/" and openid.identity="https://me.yahoo.com/jbradley" are retuned by Yahoo.

There is now no relation between my input identifier, my claimed_id and my authentication.

The openID 2.0 spec talks about what to do if the openid.claimed_id changes and how we re validate that. In this case the openid.claimed_id hasn't changed only the openid.identity is different.

Clearly I was a fool for delegating my ID to Yahoo without understanding the consequences.

I did find that Plaxo detected the modification of openid.identity and failed to reverify that Yahoo was authoritative.

Other sites we won't talk about. I need to verify that my failure at Plaxo was Michael correctly detecting something was wrong or some other error I might be able to overcome.

OpenID 2.0 adds some good and powerful features. However RP's and OP's need to understand the changes to the architecture.

I am just starting to look at Directed Identity issues for XRI and how a iName OP would support the new features.

=jbradley
PS I have changed my rel tags back on thread-safe.net so forget trying to get into my accounts using this:)

[OpenID] Calling OpenID 2.0 editors

2008-03-12T22:55:00Z

There is a discussion on the openID general list that a number of people have asked me to comment on.

I am not going to reply to the list because I don't want to encourage them. I will however share some thoughts around openID identifiers.

openID 1.0/1.1

Way back over a year ago(forever in internet time) Brad Fitzpatrick had a simple notion, he wanted to enable people to claim there personal blog URL's when making a post on another blog.

So the openID was born as a concrete identifier of a resource you control ie you BLOG. In my case thread-safe.net is a concrete identifier for my BLOG, and through putting some rel tags in my HTML I can express an authentication endpoint that will verify my claim of being the person who put those tags in the HTML of the page.

Yes there is a authentication service that I can run or I can use one run by a third party.
This works because my page has one or more rel tags (Meta Data) in it that tell a Reliant Party (Web site) how to verify the identity of a person claiming ownership/control of that URL identifier.

In openID 1.0 there are two elements openid.server and optionally openid.delegate.

A website can use openID to prove to itself that I have control over my input identifier by redirecting me to the URL containd in openid.server with ether my input URL as my identifier (openid.identity) or with the contents openid.delegate as my identifier.

openid.identity is and always has been an opaque identifier passed to the OP. There is no grand significance to it. In my case it isn't a url its an iName =jbradley. The convention of using the input identifier as a local identifier for the OP is just that. The openID protocol assumes that you want to use a normalized version of your input identifier as your "OP-Local Identifier"

My input identifier "thread-safe.net" is normalized to "http://thread-safe.net/" and used by the RP as the RP sees fit.

Life was good with openID 1.0/1.1.

An openID was a URL that returned some HTML with metadata that allowed you to prove to another site that you controlled that URL in some way.

OpenID 2.0 The rise of complexity.

People saw that openID was good, but could be better if it did just one more thing. Some people wanted iNames (XRI) others wanted different authentication systems LID etc.

So people looked at the example set by XRI and its XRDS meta data and thought by golly if we discover meta data for an identifier we can use openID, LID, or SAML to allow someone to prove ownership of that identifier.

True but that doesn't change the fundamental nature of the URL. An iName =jbradley for example always resolves to a XRDS document, there will be forwarding and contact services as well as an authentication service contained in the XRDS.
An iName as an identifier is all about discovering meta data. A URL as an identifier is still about the resource identified by resolving the URL with a browser.

In XRI resolution there is something called a "Canonical ID" the resolution process enforces this. Think of it this way the CID is the address of the XRD document.(XRDS documents returned during are comprised of XRD documents the traversed, if you care)
While any given address must be unique there may be many routes to the address. An iName like =jbradley is just a route to a CID in fact =VE7JTB is a route to the same CID.

This allows for a user to have multiple identifiers that all use the same authentication service with the same "OP-Local Identifier". The CID from the XRDS in the XRI case.

In XRI it is "VERY STRONGLY RECOMMENDED" that an iNumber be used as the CID. iNumbers are not reassignable, so work to detect identifier recycling. If my iName =jbradley gets purchased by some one else after I give it up it MUST have a new and different iNumber for the XRD it resolves to.

If I decide to get a new iName =thread-safe and point it at my existing iNumber, I can use the new name to log into any site that is using my iNumber as a primary key.

I can also move my iNames and iNumbers between providers if an OP offers me a more compelling service. Something that is hard to impossible to do with URL's.

I happen to like iNames(XRI) because they are abstract identifiers with a resolution protocol that allows for service discovery. (There are other advanced features of XRI that I have not listed)
Not everyone (Brad Fitzpatrick and others) agree with me. The argument is that we can retrofit the features of abstract identifiers onto the concrete URL identifiers.

The first step to add functionality to the URL identifiers was Yadis this added a way to retrieve a XRDS document via a URL.
There is however a subtle difference, an XRDS retrieved via XRI is constructed by the resolution process and the CID is validated. A XRDS retrieved via a URL is just a special form of XML document and has no validated CID.

So to deal with the identifier reuse problem at places like Yahoo and AOL there needed to be something like the XRI CID.
The decision was taken to add something new to the 2.0 protocol "Claimed Identifier", this is intended to be the primary key for the Reliant Party to use. In the XRI case the thing to do was obvious, use the CID returned in the XRDS from the service discovery process.

In the URL case there is no CID in the XRDS and if there was one we couldn't verify it due to the resolution process. There was a proposal to use "Canonical EquivID" in the XRDS and verify it according to the XRI rules. It would have worked but some people didn't want to enforce the use of an XRDS to support identifier recycling.

The adopted solution has the RP relying on the OP to provide it with a URL to use as its primary key during the authentication process. This is the infamous and unfortunately named "Claimed Identifier". It is a mistake to think of it as anything other than an identifier that the OP is authoritative for to be used as the primary key by the RP.

The relationship between the "Input Identifier" and the "Claimed ID" is a one way one at best, they are not intended as synonyms.

When I do discovery on my URL "thread-safe.net" I may be redirected to "https://xrds.thread-safe.net/jbradley". The URL as a result of all redirects is my "Claimed ID" for sending to the OP. The OP may append a fragment ie "https://xrds.thread-safe.net/jbradley#12345" and return that as the "Claimed ID". This returned "Claimed ID" is what must be used as the primary key by the RP.

If we think back to openID 1.0/1.1 I have now proven that I control thread-safe.net but my OP wants the RP to use "https://xrds.thread-safe.net/jbradley#12345" as its primary key. The RP could and should use my original input identifier for display purposes.

The same goes for an XRI in that if my input identifier is =thread-safe I want the RP to display that and not my iNumber =!BF81.FD97.C81B.B4E5. I have only indicated that I or my OP wants =!BF81.FD97.C81B.B4E5 used as the primary key.

A reasonable question to ask is why use the product of the redirects as the root of the primary key at the RP and not the "Input Identifier"?

The answer has to do with people being cheep, wanting to keep the bar for adoption low, and how that conflicts with security.

A iName uses secure XRI resolution to retrieve the meta data, so things like the CID and OP URL can be trusted.

A URL may or may not point to a web site that has a SSL cert covering the URL being used. If the meta-data is retrieved over a non SSL connection without certificate verification you are asking to have your account hijacked via DNS poisoning.

So this leads to a two step normalization process for the "Input Identifier":
1. Prepend http:// if necessary, this defaults the identifier to non-SSL for maximum compatibility.
2. URL Identifiers MUST then be further normalized by both following redirects when retrieving their content, this allows an OP to force the retrieval of the meta-data to be over https.

If my OP is doing its job, my primary key is always a https:// URL so that if someone poisons the DNS cache they can spoof the http:// version of my identifier but not the https:// version. The RP must not consider the two URLs synonyms for the purposes of authentication. They may be synonyms for display, and I may have proved control over both, however only the URL that results from following all redirects is valid for securely logging me into an account.

I really don't care about the type of redirects HTTP follows. The primary key must be based on the URL that the meta-data is returned from for security reasons.

Changing this part of the openID 2.0 spec would break the security model for URLs.

I do however recommend that the original intent of the 1.0/1.1 spec be maintained in that the user has proven control of the concrete URL identifier, and that can be used to indicate the persons blog or info page for display or linking.

=jbradley