« Animoto | Main | OpenID & FOAF »

November 19, 2007

OpenID and metadata in URIs

As Andy reports, at the Eduserv Foundation OpenID event, there was a good deal of discussion around the question of the levels of trust which "relying parties" - service providers - might ascribe to different OpenID identity provider services, with some of the participants from educational institutions suggesting that, as relying parties, they might trust only OpenIDs provided by their own institution (as an OpenID identity provider), or at least by some named set of "friends". (See, for example, the comments by Sean Mehan and Scott Wilson). I guess this becomes particularly relevant when you consider that there are OpenID identity providers like Anonymous OpenID which issue me with an OpenID (and respond to OpenID requests from a "relying party") without requesting any authentication on my part.

I think this touches on an important issue related to the use of URIs generally, and the use of URIs in OpenID in particular. i.e. I think it's important here that we take care to avoid falling into the trap of conflating what are two quite distinct assertions:

_:person hasOpenID some-URI-with-"xyz.ac.uk"-as-domain.

and

_:person isCurrentlyAffiliatedWith the-academic-institution-which-owns-the-"xyz.ac.uk"-domain .

or if not conflating those two assertions, then assuming that the latter can be inferred from the former.  And I'm certainly not suggesting that either Scott or Sean were doing this, I hasten to add - but I'll labour the point because I have seen discussions elsewhere where I think this has been a problem.

Take a concrete example. Until eighteen months or so ago, I was an employee of the University of Bath, and if the University had assigned OpenIDs to their staff, I might have ended up with an OpenID of something like http://openid.bath.ac.uk/petejohnston. And I could have used that URI as my OpenID when authenticating both to services provided by the University and also to services provided by other agencies.

And when I left the University, I would have expected to be able to continue using my University-supplied OpenID as part of my authenticating to various services. My authorisation to use the resources licensed by the University for current staff and students of the University would have been revoked, certainly. But I would have expected to continue to use that OpenID when I authenticated to services that I was still authorised to use (because my access to them is not conditional on my membership of the University of Bath): I don't want to lose access to my Magnolia account just because I changed jobs.

And conversely, of course, I currently have OpenIDs supplied by a range of OpenID identity providers, many of whom I've had no other relationship with except to sign-up to obtain an OpenID: I have no other affiliation with the organisations that provide those services and own the domain names on which those URIs are based.

So it would be an error for a "relying party" to make decisions about my affiliation to the University of Bath (and issues of authorisation dependent on that) purely on the basis of the fact that my OpenID URI was issued by the University of Bath. If such access is dependent on current institutional affiliation, those relying parties need some piece of information other than my OpenID URI alone to assess whether I am currently authorised to access resources.

I think this is really a case of the "metadata in URIs" question which is the topic of a finding of the W3C Technical Architecture Group. Essentially that document says that it is quite legitimate (and indeed may be useful) for URI owners to encode some metadata about the (unchanging attributes of) identified resources in the URIs they assign to those resources, and those URI owners may describe the conventions they use in specifications they publish. The users/consumers of URIs assigned by others, however, should - in the absence of such an explicit licence to infer metadata from a URI - be cautious in the inferences they make based on URIs they encounter.

TrackBack

TrackBack URL for this entry:
https://www.typepad.com/services/trackback/6a00d8345203ba69e200e55071e7a08833

Listed below are links to weblogs that reference OpenID and metadata in URIs:

Comments

One of the use cases for OpenID in big and de-centralized organization like universities is its ability to work as a light-weight SSO and, yes, authorization mechanism. Say the Education department wants to set up wiki, editable only by University members. Permitting only university issued OpenID is a good fit for this use case: the Education department does not have to ask permission from the central IT bureaucracy, the IT bureacracy does not have to worry about the security of the Education Department servers (which they would have if they gave ldap access).

Another example: I run a social network open only to my universities members. I only need to know whether this person on the other end of the network is affiliated in some sense with my University. If they have access to a openid.usp.br url, that's proof enough for me. And its better than an email-based proof, because it does not confound two very different things: identity and a comunication mechanism.

So yes, what you say is true, controlling an OpenID url does not prove anything except that it was probably issued to you by the institution, but this in itself can be extremely useful to de-centralize access mechanism within the institution itself.

Is there any way to allow an openid user to associate different urls from other 'identity providers' as equivalent? I think that it would solve the issue of you losing access to your magnolia account when the university revokes access to your openid url.

@ewout: Do you think that Universities would be comfortable saying that they will only ever issue OpenIDs within their namespace to University members? I can assure you that we would not here at USC... there's too much emphasis on marketing and branding. I'm sure there are some people here that would love to give an account to anyone that can spell USC. Realistically, there are a number of non-member guests and affiliates that already have accounts but with little-to-no affiliation with the University. We could not possibly say that a "usc.edu" OpenID means anything more than the person has some form of an account at USC. Anything more than that (like affiliation) would *have* to be conveyed through additional attributes. Fortunately, that is entirely possible with OpenID+AX.

@james: there is nothing in the OpenID spec relating to this, but XFN's rel="me" links should provide the necessary framework for determining ID equivalence. Plaxo has a nice demo of that at http://www.plaxo.com/info/opensocialgraph.

Isn't a University issuing an OpenID like it issuing an email address. Having recently changed jobs, I've just learnt the hardway that using my employment based email as a 'personal' email wasn't such a good idea. I now try to separate out these functions to a larger degree.

Won't the same be true with an OpenID - you can't work under the expectation that it will be available to you once you leave the institution. If you have services that you sign into as 'you' rather than 'member of University X' then you may have to use an OpenID provider that 'you' have paid for?

@Owen, I kinda struggle to reconcile that suggested "institution-centred" approach with a context of "lifelong learning" where I do want my identity as a learner, and my access to resources on the Web, to transcend my (temporary) affiliation to/membership of a single institution.

The comments to this entry are closed.

About

Search

Loading
eFoundations is powered by TypePad