In trying to answer Saronson01’s question I seem to fall into a total flow of consciousness that might make no sense to anyone but me… sorry. I will try to frame this more clearly soon. Keep the questions coming as that is what fuels the fire...
When "adding" services to an XRDS document how are the services used, viewed, etc.? It seems that there is a missing piece regarding how a service is actually "consumed." How would the i-name @images*andy utilize a flickr feed?
Now I think I understand the question.. but if I’m answering the wrong question restate and I’ll try again…
- I go to some application… it may be a web app or it may be a thick app… doesn’t matter.
- I enter my i-name into the app.
- The app knows what service it is looking for so it performs Service EndPoint (SEP) resolution for the service it is looking for and gets back the needed information about that service, where it can be found and how it can be accessed.
The most common current usage of this pattern, today, is to find authentication services, i.e. To enable SSO. In that case the ‘type’ that is looked for is http://openid.net/signon/1.0
EZIBroker is in the process of building and rolling out an Age Claims Service that can be associated with an i-name… Any relying party who can provide the right credentials to the age claims service may have access (under the users control) to age claims about that i-name owner. The XRDS provides the glue between finding the authN service for the user to know they are who they claim to be (ok.. have access to the credentials for that account) and the Age Claims Service that provides necessary claims for the i-name user to buy their beer on-line.