I was playing around on the new Google Calendar and searched on 'identity' in the available public calendars. I hit on a calendar owned by an identity colleague. Interspersed amongst industry events were a few that appeared out of place, e.g. 'Girls Night Out' and 'Take kids to school'.
My own personal calendar has lots of the latter type events (but distressingly few of the former) so I can definitely sympathise with the confusion by which these private events snuck into the public calendar.
It also points out an interesting issue, the private events that snuck in actually belonged (in the sense of who was going to be attending) to my colleague's wife. Google allows you to create separate categories for events (labelled as different calendars under the same Google account) and treat them differently with respect to sharing - which is what my colleague (call him Husband) did.
Also possible would have been for the lady of the house (call her Wife) to have created her own calendar under her own account, make it public and exportable, to be then imported into that of Husband. Likewise for the reverse direction - each would see their own events as well as those of their partner.
Another possibility would be for one or the other to define a 'Family Calendar' of shared events (e.g. dinner parties, vacations, etc) - this to be imported into both the personal calendars of Husband and Wife. When Husband viewed his calendar, he would see his own events as well as the shared family events - likewise for Wife. Importantly, neither would need see the details of the personal events of the other (except perhaps availibility for scheduling purposes).
This concept of shared resources (the family calendar) is important to operators and ISPs because there are situations in which an authentication, while insufficient to enable access to private resources, may be sufficient to enable access to such a shared resource. This sort of authentication is generally passive - consisting of the user opening some communication channel - and so of interest to those who provide such communication channels.
Consider Husband accessing the internet through the home PC he shares with Wife. The implicit authentication performed when he accesses the Web from the static IP associated with his ISP account can be sufficient for the ISP to identify him as one of the set of users associated with that account, and who therefore can view the shared calendar. But, because the "credential" by which Husband authenticated to the ISP (possession of that IP address) is shared with Wife - the ISP would be unable to determine which of the two was actually authenticating. But that's OK, because the access rules for the Family calendar would stipulate that anybody coming from that IP address would be allowed to view (and likely change) the Family Calendar.
If however, Husband then wished to view his own private calendar, the ISP would need to authenticate him as an individual in order to disambiguate him from Wife. At this point, he would then present a password etc unique to his account - the shared credential no longer sufficient for the task at hand.
When the resources being accessed are remote from the entity authenticating the user (e.g. if Google was hosting the various calendars but Husband and Wife were being authenticated by their ISP) then the Service Provider (Google) needs a way to stipulate to the Identity Provider (ISP) its requirements of an authentication (e.g. I need something that pinpoints the user as an individual).
Fortunately, SAML 2.0 provides a framework that allows Service and Identity Providers to discuss just such details about how the user authenticates (and much more) - its called Authentication Context. Work is currently under way in the SSTC to explore whether the existing Authentication Context mechanisms in SAML 2.0 need be extended to support this concept of Shared Credentials.
No comments:
Post a Comment