March 2009


When is informed consent really consent, and not just paperwork? My local newspaper carried an interesting article yesterday where professor Stein Kaasa at NTNU stated that the paperwork for getting informed consent for participation in research projects from cancer patients has grown too complex.  The text in the consent form is three times what is was some years ago, and the added text is mostly legalese (legal issues, economic terms, privacy information, data storage information).  He states that this is preventing his patients, mostly ill and elderly, from understanding the issues involved in volunteering for research projects.  I believe that he is fundamentally right, not only for elderly patients.  The user/patient’s need to understand consent information should override the need for us to add complex disclaimers.

How many of the Microsoft Office users are aware that you agree to not use Word’s media elements to create scandalous works?

You may not create obscene or scandalous works, as defined by federal law at the time the work is created, using the Media Elements

And that text is snipped from the first part of the EULA, a part that innocent users might see while scrolling through the text to be able to agree and then get work done.  One of the major roadblocks for security is the Press-OK-to-continue-syndrome.  Because the questions asked are either self-evident or too complex to understand, the only possible answer is YES.  This is why I believe that complexity breeds consent.

Back to the cancer patients, where almost all agree to participate in research.  The proposal from professor Kaasa was to use established channels: spend some time in the conversation with the patient to inform about issues (mostly done by research nurses).  And he states that the hospital must be able to take on more of the administrative burden with regards to the consent forms, possibly also take on board more responsibility as an organization instead of outsourcing everything to each project.

How much of the policy work done today is about disclaimers, where we are covering our backsides?  How much is really needed?  How formalized should policies be?  How much of the formalization of policy must be visible to the end users?

Advertisements

Passwords are like toothbrushes, you should keep them to yourself.  And discard them, and get a new one,  if they have been used by others.

You should feel slightly disgusted if someone else helped themselves to your password, or forced you to share your toothbrush.  Disgust is a useful feeling for security purposes, but not enough to build any policy on. Policy must be built on finding the real life requirements for passwords.  Real life includes thinking about cost in money, cost in time, possibility of enforcing rules, ease of use and the culture of the user population.  Never give a rule that you cannot enforce.

Policy must state requirements for password, but still be useable for real people.  This includes not forcing users to change their passwords too often, since that leads to them writing down password (or cycling through a small list, if they are allowed).  Users are fundamentally smart, and tend to do things that benefit them.  One of the things that benefit users, is laziness, or “not spending valuable work time confirming to stupid rules”.  No-one is employed to conform to security regulations, they are employed to teach, administrate, support, solve problems, treat cases and such-like activities.

Password regulations should think about stuff that users may encounter, such as being able to type in a password on a foreign keyboard (where do I find Æ on a French keyboard?), especially if they are likely to travel and use Internet cafes. Then on the other hand, we should be careful not to spend too much time thinking about unlikely situations.

Higher education and research federations are using the eduPerson schema, where eduPersonAffiliation and eduPersonScopedAffiliation is the basic way of handling roles. The only well-defined roles consist of the vocabulary for eduPersonAffiliation, with some local extensions.  Some federations have defined other well-scoped vocabularies for roles in special attributes.  eduPersonAffiliation is used in a large number of applications.

I would like to see some more simple roles for learning, staff duties and high performance computing.  Currently I am trying to gather the information that will make it possible to make some small steps towards semantic interoperability for roles within our community, as requested in a recent report on Strategies for shared administrative services in Norway (Norwegian only) and by several universities.

Learning roles should take up the vocabulary defined in IMS Enterprise, which is used for populating e-learning support systems (Fronter, It’sLearning) for courses: Learner, Instructor, Content Developer, Member, Manager, Mentor, Administrator, TeachingAssistant.  These values are also used in Norwegian Standard NS4170, Person Information Flow in Education (PIFU).  Mappings from the roles in FS, the shared Student Registry are well-defined.

Research roles include project manager, project participant, main author and co-author.  Other research roles may be related to the grid community.  Work on Short Lived Credential Service (SLCS) based on federated login is going to give us more information on the role requirements from the grid community.

Administrative staff comes in the flavors of: finance officers, HR, archivists, IT and student registrars.  All of these groups are present in universities and colleges, and the functions of a staff member is linked to a specific place in the organizational chart.  This should, in theory, make it possible to identify roles and use these roles to limit access to specific services.

Currently the web services seems able to handle information about a single end user, so the roles must be mapped onto each user account (probably in LDAP or such-like).  In addition to this information, there should be restricted meta-information about the groupings/roles themselves available.  And having the roles represented as groups (isMemberOf) in the local LDAPs could be helpful.

Earlier attempts to define semantics for shared roles has failed, mostly due to the inability to define a problem statement.  My problem statement so far:  Define semantics for shared roles that are preventing interoperability or administration of security domains in key IT services for staff administrative services, learning and research in Norway’s higher education.

Still work to do on these issues…  to be continued

For Ada Lovelace Day I’d like to point to the eminent work of  Eve Maler in the fields of security,  identity and XML.

Her ability to select the important bits and leave the chaff behind is an example to the rest of us.  If you have not read the Venn of Identity, please have at look at the paper.  The issues of SAML, OpenID and InfoCard are layed out as described in the abstract:

Federated  identity management  lets users dynamically distribute  identity  information across security domains, increasing  the  portability  of  their  digital  identities.  It also  raises new architectural challenges and significant security and privacy issues.

Some recent work that Eve Maler is involved in includes work with (among others) my colleague Andreas Åkre Solberg on an Interoperable SAML 2.0 Web Browser SSO Deployment Profile , where the bare bones of interoperability are laid open for the world to see.

I have yet to meet Eve, but keep track of (some of) her work and knitting by reading her blog.

Technorati Tags: AdaLovelaceDay09, ALD09

Nicole in the UK (JISC Access Management Team) writes her three new access and identity management mantras:

1. Content is Not King.
Access management is not about getting x user to y resource but about the management infrastructure of your website.
2. Thou shalt not make users generate accounts.
This does not just focus on the need to use organisation centric federated access management on websites, but recognise and builds in to the larger question that institutions may in the long term chose to broker user-centric identities rather than provisioning identities. Service Provider managed user accounts are generally to be seen as bad though!
3. We are all Service Providers now.
It is important for institutions to think of themselves as Service Providers to their users, and think of the controls they need around those services to provide a good service to the end user. If you expect users to have federated accounts to access content at Wiley or OUP, why not have it on your website / VLE / Library Portal?

The third point goes directly into the debate on Web 2.0, where we are truly all contributors (and thus we are all Service Providers in the SAML lingo).  However, the access management infrastructure for light-weight contributors is lagging behind.  The current federation infrastructure is organization-centric, and this makes it hard to re-use the same infrastructure.

I would restate the mantras as:

  1. Infrastructure matters
    Federations regulate authentication (SSO/SLO), information sharing model (attribute definitions and semantic interoperability) and security models. Security must be good enough, and the access management federations should be exploited.  Align user management with the organizational procedures/infrastructure.
  2. Thou shalt not harass thy users
    Do not force users to have more passwords than they can possibly remember, do not force users to have more user accounts than they are able to manage, do not force users to register new accounts.  Provide Single Sign On and Single Log Out to your users.  Give your users the information needed, including consent and security.  Users are smart, and will do what benefits them, if given tools to help themselves.
  3. You need to participate: we are all Service Providers
    Web sites that have access control do benefit from a shared access management infrastructure.  One size does not fit all, but all that need to use Medium and Large access management should federate to provide their users with a non-harassing Single Sign On and Single Log Out environment.

Norway was password protected before Schengen (and 9/11), when they standardized border crossings and security procedures.  You walked in to the passport control, briskly, and announced “Norsk”.  If you could pronounce it, you earned the right to enter the country.   This procedure worked nicely if you were white skinned, or obviously belonged with some white skin people (all Norwegians are tall, blond and blue eyed; except some of us).  The entry procedure was similar to the Shibboleth described in chapter 12, Book of Judges.  “Norsk” (Norwegian) is remarkably hard to pronounce for foreigners, including Danes and Swedes.  Since a language is a dialect with an army, Norwegian is a language separate from Danish and Swedish.

I am currently abroad, in the fair mountains of Andalucia, visiting my in-laws who spend their winters here.  Travelling with children involves more paper work than it used to, when I was young.  Our two sons had to get a passport each, even if Spain is part of Schengen where (in theory) there is no need to carry a passport when crossing borders from Norway.  When we return, they are not likely to check at the border, since the passport control has been delegated to the air line operators. Delegation of authorization to the access point is common procedure, but leads to differences in the pragmatic day to day implementation of the authorization (as those of us trying to travel with KLM to the Netherlands without a passport knows,  even if we had plenty of other valid ID).

The formal requirement for travelling is having identification papers, but in practice the only identity paper available for small children is a passport.  Back when I was a child, you put the names of children into the parent’s passport, and then you could take the children with you.  This was called “writing the child into the passport”, and was sufficient security until someone discovered that most children have more than one parent (and some parents have multiple passports).  Then it was decided to treat children like persons, with regards to passports.

I know a Polish linguist who regularly entered the country by using the password procedure (or by putting on T-shirts proclaiming the benefit of Nynorsk and sheeps heads, something only indigines from Voss does in public) in the late 1980’s.  Using passwords is of course vunerable to attacs, but the risk from visiting linguists could be deemed low enough to be acceptable.   Providing background discussion to the risk analysis is rarely done, and this impedes the transparency of the authentication and identity solutions we encounter.

Feide‘s latest update of the federated login service includes a major revamping of our consent information. Every user gets splashed with a web page about what information the service requesting the login is demanding, and given the option to opt out before information is transferred. The software behind the consent module in SimpleSAMLphp was developed in WAYF, the Danish higher education federation. Consent user interface

Informed consent is an underpinning of most privacy legislation in Europe, but has been given lip service without real implementation. The two main reasons for this is lack of interest and bad user interfaces. Lack of interest is understandable since the consequences of not having informed consent are ignorable.  Bad user interfaces, where the user is exposed to either legalese or tech-talk in stunning doses, has killed most emerging implementations.

The new Feide login has three steps to login:

  1. Chose where you are from (sticky information, sticks in a cookie)
  2. Write username and password
  3. Consent to information transfer (sticky information, sticks in a database)

Where you are from is remembered for weeks, but you have to supply this information again if you change your computer since the information sticks in a cookie. The information times out over the summer holidays.

Username and password needs to be reentered every session, but gives you Single Sign On between separate services.

Consent to information transfer is stuck in a database, unless you chose not to remember consent. If you chose to remember, the consent may be removed using the consent administration service.

Some users get confused by this new third step in the login process, especially when they are redirected as part of SSO and have not seen the login page for the service they are redirected from. Other users are happy to get presented what happens to they personal information elements on the wild wild web.

Consent administration is a separate service, where you at a glance see all the information requested for transfer by each of the services you have ever logged in to using Feide.

User interface for consent administration

User interface for consent administration

End user approval of the consent service is going to be interesting.

Next Page »