Why is the configuration called metadata?

Posted on 03/02/2012 by david

Metadata is the ‘configuration’ of the identity federation.

In a point-to-point-federation, where all entities must know each other, the configuration needs to be updated at all entities at regular intervals. Thus the name ‘metadata’.

In a hub-and-spoke model, like WAYF, each IdP and SP only needs to know the configuration of one other entity, namely the hub. The ‘metadata’ is updated much less frequently and can be thought of as almost static.

In principle it should only be updated if the certificate of the hub is changed.

Posted in Federation architecture, Federation stuff, Hub and spoke | Leave a comment

Enable (age) verification – don’t enforce it

Posted on 23/11/2011 by david

Knowledge about other peoples age is of big importance when building relations. As is gender, name etc. Also in the digital world.

Still, most systems aiming at protecting typically young people (eg. chat rooms) seem to take the (wrong) position that only young people should talk to young people, by denying access for ‘older’ people.

To the best of my knowledge none of these sites are succesful – and with good reason, as hardly anyone can imagine the positive sides of young-people-only streets, shops, parks etc.

A tool to build trust relations more easily in the digital world is verification services. They should be used to enrich interactions inside services, not as filter for entering a service. Identity federations are excellent for this purpose as trusted third parties (IdPs) can at any time be asked about what they know about a user in eg. a chat-room.

This way conversations can begin and evolve until the stage where one part ask the other to proof a certain quality, eg. his claimed age. If it’s different from what was initially told, it’s up to first user to decide what to do. It might not be critical – or it could be. That entirely up to the users to decide and deeply depends on the context – which no system so far seems able to grasp.

Enabling verification of age, name, email adress, postition etc. as opposed to enforcing certain access criteria leaves room to discuss with your children and other young users how to deal with the various situations and contexts – without having a simple, predefined set of rules of how to behave at hand. Just like in the real world …

Posted in Federation stuff, Privacy, Usabillity | Leave a comment

Withdrawel of consent only withdraws the consent …

Posted on 23/11/2011 by david

To let users consent to data exchange is only one side of the coin – they must also be able to withdraw their consents at a later time. This follows from the legal definition of consent but only applies if information about the consents is stored eg. to allow the user not to consent to the same data transfer again and again.

If a user at some point in time should choose to withdraw her (stored) consent to data exchange this must of course be supported by some sort of user (friendly) interface – but note that by deleting information about a given consent to data exchange it does not follow that also the actual data, which was then transferred, must also be deleted.

It is only the stored information about the action of consenting that is deleted.

Weather the receiver of the data about the user, typically a service provider of some kind, is obliged to delete the user info in question, is up to the local legislation to decide.

Posted in Federation stuff, Privacy, Usabillity | Leave a comment

What’s the ‘purpose’? On consent dialogues, also in interfederation scenarios

Posted on 10/05/2011 by david

When users consent to data exchange, the consent dialogue must be ‘informed’. This means the user must understand what is going on. A tall order…

The amount of personal information (the attribute release policy) must be balanced with the ‘purpose’ of the service receiving the data. Only data necessary for the functionality of the service may be transferred – and only if the user agrees (consents), of course.

After thorough discussions with both usability and legal experts on handling of personal data, the recommendations for purpose descriptions may be summed up as:

- purpose descriptions should be short. Very short (they should not be like most AUP’s). As a consequence WAYF has an upper limit of 200 characters which is a bit more than a SMS text message.

- purpose descriptions should be recognizable to the users, also when going to different services. Not at least to build confidence in consent functionality. WAYF therefore uses a template for purpose descriptions, see: http://www.wayf.dk/wayfweb/howto_describe_the_’purpose_of_the_service’.html )

So far, this seems to work out just fine. But think about what happens when services become available in multiple federations. One example is the Nordic Kalmar2 Union (http://www.kalmar2.org) ? As consent dialogues are managed by identity providers (IdPs), agreement on both form and content should be reached.

How do we ensure that purpose descriptions originating from federation X can be used in federation Y? Do the various SAML implementations behave the same way?What if the templates do not fit? What if there are no templates at all? What does it take to transfer purpose descriptions between federations?

This, and presumably many more questions must be handled in the growing world of both federation and interfederation.

Posted in Federation architecture, Federation stuff, Privacy, Usabillity | Leave a comment

How transparent is your federation?

Posted on 24/03/2011 by david

In the eID federations space, the legal aspects of handling personal information is new to most developers working with the technical side of things – as well as the concept of federated identity, protocols etc. is new to most legal specialists.

Still, both groups discuss issues with the ‘transparency’ of federations. But be careful, they mean different things which might be a source of confusion:

When layers want transparency in federated environments, they mean that end-users must be fully aware of what is happening, why and how. They emphasize that services must have a ‘purpose’ and that attribute release policies must abide to the principle of ‘proportionality’, minimal disclosure, informed consent etc.
When developers and technically minded people want ‘transparency’ they imagine the infrastructure being invisible to end users. Even though middleware plays a crusual role in the federated environment, it should not be something for end-users to worry about. It should be ‘transparent’.

In worst case scenarios these two, only partly overlapping views, might lead to misconceptions about how and what the infrastructures should develop into.

This is particularly true in discussions about how visible hub-and-spoke federations should be to end users, SPs and IdPs. The federation hub is certainly there – but do we want the users to notice and know about it? In some cases yes, in others no – but one way or the other it should definitely be ‘transparent’.

Richard Feynman, American physicist, has made wonderful observations about how people perceive the same thing differently. Have a look at http://www.youtube.com/watch?v=Cj4y0EUlU-Y

Posted in Uncategorized | Leave a comment

(ARP) size matters – and less is more!

Posted on 23/03/2011 by david

On the importance of minimal disclosure in federated environments

People MAY disclose information about themselves (and still more chose to do so systematically). Nothing can or should stop them as long as they are aware of the implications.

Infrastructures like eID federations, on the other hand, MUST NEVER systematically disclose excessive information about users – and should always ensure that users are aware of transactions involving information about them. The general rule should be to collect the users’ informed consent to data exchanges – the exception should be not to do so – and in all cases users must be able to easily be informed about what happens and why.

When service providers (SP’s) join eID-federations they must state what information about the users is needed for authorizing access to their service. That is call the ‘attribute release policy ‘ (ARP) and defines the amount of personal data that will be transferred from IdP’s to the SP each time (!) a user tries to access the service.

In most cases federation operators recommend ARPs for SPs connected to the federation (it resides in the federation metadata) – and IdPs tend to blindly accept it, as is, and with no further considerations about its’ correctness.

The purpose of all services must be described and the ARP must be ‘proportional’ to this purpose – only the data necessary for the service must be transferred. Keep in mind that services may later ask users for more information, but they should never recieve anything more than strictly needed – and certainly not in any systematic way provided by the federation.

So, if a federation encourages IdPs to exchange more data than strictly needed – that might at some point put the users at risk. The size of ARPs therefore certainly matters – and less is more.

Please note that it rarely makes sense to discuss data ownership rather than who is responsible for the data.

Further information about why minimal disclosure is a ‘good thing’ is nicely explained by Kim Cameron at http://www.identityblog.com/?p=317

Posted in Uncategorized | Leave a comment

User consent can be governed centrally but presented locally – letting the federation wear the “Cloak of Invisibility”.

Posted on 17/03/2011 by Jacob Steen Madsen

I saw a mail where Scott Cantor said that identity proxies (to his big regret?) might be the only way to make consent to data transfers scalable. Operating a federation hub I’ll just add to Scott’s statement that ensuring that users gives consent does scale in this setup – even though there might be dislikes against the architecture.

The other thing was, that his email got me thinking in different terms. We are at WAYF  focused on usability issues in hub-and-spoke federations. We have implemented proxy end points for all connections to the hub so service providers can connect (they think) directly to identity providers – just like in P2P federations.
I will give a presentation at TNC2011 addressing the hows, why’s & results of that. A paper will be published on the subject.
The main thing is that endusers will not necessarily meet the discovery service provided by WAYF anymore. Service Providers may operate their own discovery services as they can in P2P federations. Hopefully that provides better user experiences as one of the key drivers has been to make the infrastructure invisible to end users. At least it makes it possible for us to piggy-bag on others’ work in the area of discovery services and usability.

The last visible sign of the infrastructure is the consent dialogue which is managed by the federation hub, presenting a generic consent module, with the federations’ skin. Why not change the consent module to let it feed the content of the consent dialogue to a local application operated by the IdP? This would leave the hard and complicated work with the federation hub but all dialogues would get the namespace, look and feel of the IdP.

A first analysis didn’t scare us of from attempting to make ourselves invisible, acting like Harry Potter wearing his “cloak of invisibility” (my colleague Davids expression). In my opinion we will bridge some of the gap between P2P federations and hub-and-spoke federations by making a loosely coupled consent-module.

The code name for the project is CORMACK (Consent Operated Remotely M…… A…… R….. K…), in tribute to Andrew Cormack (JANET) whom we’ve got much inspiration from via the discussions on consent he has fascilitated.

Posted in Federation architecture, Federation stuff, Hub and spoke, Usabillity | Leave a comment

Attribute release policies made simple

Posted on 15/03/2011 by david

Hub-and-spoke federations are characterized by the fact that each connected service provider only recieves attributes from a single entity provider, namely the federation hub. This hub acts as an IdP-proxy on behalf of all connected IdP.

This approach has several advantages:

Simple metadata management for service providers

Service providers only need to keep knowledge (metadata) about a single entity, namely the federation hub (the IdP-proxy). This simplifies the setup and knowledge required to operate a service in a federated environment.

Use of standard attribtue release profiles

Standard attritbute release profiles are profiles suggested by the federation operator. To simplify negotiations all exeptions from the standard profiles must be documented in the contract. Typically this is not a problem as most accept the notion of standard profiles. The discussion is then reduced to a question of difinition of the purpose of the service and deciding on the appropriate attribute profile.

Negotiation expertice

The federation operator has special expertice in the legal setup, good knowledge about the attributes available and more experience in dealing with negotiation of attribute release profiles than most IdPs have or can maintain over time.

Strong negotiation power (SP cannot press individual IdPs)

The federation operator is negotiating the attritbute release profile on behalf of all IdPs and it is in practice impossible for service providers to influence the IdPs individually. As the number of IdPs goes up, the stronger the negotiation position of the federation operator gets.

 

(No) commercial interest

As the federation operator is not part of the business relation between services and IdP’s, the negotiations stay focused on the issue of balancing the attritbute release profile with the purpose of the service. Based on the principle of minimal disclosure.

 

Standard contracts

Since all services connect to the federation hub, a standard contract may be introduced. If accepted, this lowers the IdPs interest in scrutinizing each contract as requirements and obligations are known to all.

Links

WAYF’s template for describing the ‘purpose of the service’:

http://www.wayf.dk/wayfweb/howto_describe_the_’purpose_of_the_service’.html

WAYF’s standard attribute relase profiles:

http://wayf.dk/wayfweb/attribute_profiles.html

Video presentation on attritbute management and ARPs:

http://www.wayf.dk/wayfweb/about_attributes.html

which is available at WAYF’s video archive:

http://www.wayf.dk/wayfweb/video_archive.html

Posted in Uncategorized | Leave a comment

Best solutions are often the enemy of good ones – Stop it and get pragmatic

Posted on 10/03/2011 by Jacob Steen Madsen

When ever we start a new project – there are always someone in the room searching for optimal solutions. I love that. Im a true beliver when it is about making things right. The big question is what right is…….

Often I talk to tech guys that misses the point that right can be a quick fix, It can be the cheap temporary solution, It can be hiring someone to do the job manually and of course often it is a good design. In other words…….It depends.

In my line of work of building a federation from scratch we were faced with that exact problem – what was right.

From a architectural point of view there is no doubt in my mind that the only right solution is building the federation in a P2P mode where we as federation operators only:

  • Distributes information on how services and identity providers can connect.
  • Makes a contractual framework for members of the federation to follow.

That is more or less what it takes.
In our context with a limited timeframe and not enough manpower that just wasn’t right…….

Right was instead creating a hub & spoke fashioned model of federations making sure that Identity Providers and Service Providers had the least amount of work possible hoping that the uptake would be big. So we ended up having a federation where we:

  • Potentially has a single point of failure (we have handled that)
  • Are able to monitor traffic in detail (we uses that proactively)
  • some minor things

Both things that I in principle do oppose. But……

I have learned over the last few years to listen to our “customers” and let them drive the development. If they have a real need with a good business case – then we must trade in on some architectural beauty in order to do what is rIght satisfying our “customers” needs.
And for us “customers” wanted ease of use as the primary thing. As it turns out we have been able to deal with the downsides of our architecture – contractually and technical. It has been far easier than we anticipated. The downsides are outnumbered by quite a margin from the benefits given to us by selecting the “good” solution asked for by our ”customers” thereby driving business forward instead of sticking to the “best” solution and slowing business down.

Posted in Federation stuff, Uncategorized | Leave a comment

The perfect federation(s)

Posted on 07/03/2011 by david

What kind of federations do we need?

Identity federations are traditionally sector specific. Because of practical reasons (people who know each other solve common problems together) and because of tradition (we tend to focus on exiting personal networks, as the cost of getting to know other people or communities is high).

As eID federations become daily business and still more applications and identity providers benefit from them the question arises: is membership of ‘my’ eID federation sufficient? Will all the services and IdPs I do business with join?

The answer will most likely be no. Instead both services and IdPs will each join multiple federations as each will serve a given context. Some federations will keep sharp focus on the target group, others will be more relaxed and open to more communities.

Interconnecting federations across sectors or national borders is one way of going about the problem of interacting in new contexts (e.g. http://www.kalmar2.org). Another solution might be to simply join multiple federations.

International services already face this scenario, as different IdP federations have different requirements, contracts, procedures etc. And it is cumbersome. See https://refeds.terena.org/index.php/Barriers_for_Service_Providers

Only few IdP’s are already member of multiple federations. But as institutions do business in various contexts they too will soon find them selves member of different federations with different scopes, procedures, legal documents etc.

The question (fear!) is how to manage all these relationships. Of course many sizes, shapes and forms of federations fit many – but could we do with less? Perhaps only a handful of federation ‘kinds’ with different trust levels?

Have a look at Malcolm Gladwells talk on horizontal segmentation of the spaghetti sauce market and think about if only a few categories (trust clusters) would be a viable path to follow?

Instead of building sector specific federations and interconnect across borders etc. maybe we should build ‘trust clusters’ independent of sectors, each handling well defined trust levels serving many sectors, countries etc? Both services and IdPs would still have a few, but not many, federations to care about.

http://www.ted.com/index.php/talks/malcolm_gladwell_on_spaghetti_sauce.html

(one of my favorite TED talks)

Posted in Federation stuff | Leave a comment