Menu

Projects:

  Higgins

  Identity Gang  

  Identity Schemas

SocialPhysics.org

SP Blog

Paul's Blog 

There is a need to be able to treat a set of related sites as a single context. There are two examples of this:

• Example #1: There are handful of sites/apps involved in the identity mashup that should be considered by the PIP and the user as a single context.
• Example #2: In the Best Buy / MVM demonstration two websites will be used. The first is a prototype bestbuy.com site. The second is a bestbuy.myvirtualmodel.com 3D kitchen modeling site. To the user (and to Best Buy) the 3D kitchen site is really just a sub-area of the overall bestbuy.com site.

In both cases a single context instance is created. For example #1 a "identity conference sites" context instance is created, and for example #2 a single "Best Buy Sites" context instance is created.

We could consider that a set of related sites are all members of a common site federation. This way bestbuy.com and bestbuy.myvirtualmodel.com are both members of the same, say, "bestbuy.com" site federation.

Federation objects 

A federation has a unique identifier. It is the URL of one of the main anchor constituent sites. A federation contains a list of URLs of the constituent sites. It also contains a list of the URLs of the notification pages (usually one notification page per constituent site, but not necessarily). 

Implementation

1) Changes to ISS (Identity Selector Service)

The ISS RSS-P processing code needs to add a lookup step to its processing. It needs to take a target URL and attempt to find its corresponding site federation identifier. If the site is not a member of a federation, then its site URL is used for the rest of the processing. OTOH, if it is a member, then the federation's URL is used for the rest of the processing instead of the site URL. Then the rest of its processing proceeds the same as it does now. That is, it creates a new context instance if it hasn't already encountered one and it returns the RSS-P feed for the user and delivers it to the RP site.

2) Notification of profile updates to all members of a federation

The .context.rss context provider implementation needs the following changes. .context.rss is the provider that implements particular context instances. As mentioned above there should be one context instance for a "standalone" (non-federated) site or for an entire federation of sites. If the context instance represents the federation of identity conference mashup sites, then whenever any user changes their DigitalSubject information within this context, all of the "notification" pages should be notified of the change. This notification is performed by adding the URL of the RSS-P feed of the Digital Subject as a parameter to the HTTP GET to the notification page. (Note: this is pretty much how HBX notifies the RP site of the RSS-P feed in the first place).

3) Management of federation data objects

For the sake of the demos at the conference, we can hard-code and store the two (BestBuy and Identity mashup conference) federation objects in the ISS sub-system (and also make them available to .context.rss).