Thread-Safe

New blog location

2011-08-23T22:53:41Z

My new blog posts are going to http://thread-safe.net. Same URL pointed to Blogger.

I just find livejournal too annoying.

A Map for OpenID ABC

2011-04-30T19:38:08Z

I posted the article on the openID blog.

John B.

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.