"All Hail the Relyingpartyrati!"
The quote "The IdP is Dead! Hail the Relyingpartyrati" is from my conclusion (reflecting the running inside joke at CIS that something has to die each year). One of my ideas is that because identification is carried out by Relying Parties, it's more correct (and probably liberating) to think of identity as being created by the RP. The best option for what we call "Identity Providers" today may be to switch to providing more specific Attributes or identity assertions. In fact, the importance of attributes kept recurring throughout CIS; Andrew Nash for example said at one point that "attributes are at least as interesting if not more so than identities".[Now it has emerged during the debates that people might use the word "attribute" in slightly different ways. I said at CIS that I treat 'attributes', 'assertions' and 'claims' interchangeably; I think we should focus functionally on reliable exchange of whatever factoids a Relying Party needs to know about a Subject in order to be able to transact. I'll blog in more detail about Attributes shortly.]
To summarise my CIS talk:
Federated Identity is easier said than done. In response, we should drop down a level, and instead of trading in abstract high level identities, let's instead federate concrete component attributes. We don't really need Identity Providers as such; we need a marketplace of Attribute Providers from which Relying Parties can get exactly the right information they need to identify their users.
- identities evolve over time in response to risk factors in the natural business environment; we need to understand why authentication has got the way it is before we rush in to federate disparate methods
- identities appear to be "memetic", composed of heritable traits relating to business rules and practices, conventions, standards, regulations, technologies, algorithms, cryptographic parameters, form factors and so on
- the dreaded identity silos are actually ecological niches; taking an identity from the context in which it evolved and using it in another is like taking a salt water fish and dropping it into a fresh water tank
- if identity is memetic then we should be able to sequence digital identities into their constituent memes, and thence re-engineer them more carefully to match desired new applications
- it is an over-simplification to think of a (one dimensional) identity spectrum; instead each RP's "identification" requirements are multi-dimensional, and best visualised as a surface.
The thing is Steve, an IdP can represent an individual. It can act as a representative of that person, allowing them to, for example, consent to send attributes back to the relying party or not (consent models are vital in an identity eco-system). It can also act as a privacy enhancement component as part of that eco-system, obfuscating or sending 'dynamic' attributes, i.e. over 18 or whatever to the RP. It can even allow, self asserted attributes, it can check the verification status of attributes and can allow users themselves to become part of the eco-system, managing and making sure those attributes, really do, represent them. The best implementation of (certainly consumer) IdP's means that, it is a proxy for yourself. An IdP is a vital component of an identity eco-system, like natural eco-systems, if you loose one part of it, the whole changes and in many cases that change is not positive. Attributes are one part of the whole, the way the attributes are managed and controlled is as important as the attributes themselves.
Steve your point about the issue being attributes not identity is well made. In my view, the fact that 'identity' systems are in fact based on presentation of attributes which have added weight if verified is the central & most enduring point being made by Kim Cameron in his 2005 Laws of Identity.
Ecoystem thinking has been very powerful in the ICT domain ever since the word 'virus' was applied to a certain form of malware which meant thinkers could see what was going on through a different lens. The dawning realisation that 'identity' systems were also part of an ecosystem began only a few years ago but I have found it very helpful in that time in changing the way those in ecological niches can be helped to understand that in fact that is their place in the ecosystem.
Of relevance here, ecosystem thinking reminds us of the subtlety of the feedback loops in any ecosystem and endless dynamism of an ecosystem both through endogenous evolution and exogenous shock which again leads to further evolution.
In this light, the place in the ecosystem of the Relying Party is contestable. Yes, they may wish to have the dominant role you suggest they might have. But that will be challenged by others in the ecosystem - individuals will seek to assert more control than simply passive RP dominance, either directly or agents for them such as IdPs offering them some control. Or climate change in the form of new technologies or new laws will come along to change who is the dominant genus in the ecosystem, for example laws might require the use of particular attributes (think Anti Money Laundering law) or limit access to others (as privacy law seeks to do with collection limitation requirements).
It will be fascinating to watch.
Susan, the problem is that the IdP you envisage comes with novel legal arrangements. Whenever we have tried to interpose new IdPs in between existing RP-Subject relationships, we've encountered trouble. The deep problem is that multilateral relationships between transacting parties are much, much more complicated than bilateral ones. The cost of switching from bilateral to multilateral is never factored into the planning of identity federations.
Furthermore, the actual cost-benefit to be gained from having new IdPs act as general purpose proxies is probably overestimated. For one thing, why should I disclose excessive PII to a new IdP only to have them reveal just my age to an RP? Why don't I carry a proof-of-age token issued by an existing Attribute Provider like the DMV? The new sorts of IdPs envisaged in the Identity Metasystem are said to be privacy enhancing but only at the cost of collecting and aggregating tons of PII where it was previously not necessary to do so. The nett privacy benefit is uncertain.
I think it depends on how you view the role of the IdP. In a user centric consumer based system (I assume that's what we are talking about as opposed to an enterprise one?) then the user account, where the PII is stored is under the control of the user. The exchange of that data with the RP is under the control of the user. The way you describe the system the same data is available just much more dispersed, the user still has to supply data, or the data has to be collated, for the RP to get at it. And also of course, an IdP does not have to store information anyway, it can act as a conduit, a central point where information can flow through it, acting within the control of the user, who can then make the consented decision to release or not, to add to data, to make changes to data to allow the data to be verified under business rules, etc, etc.
BTW who is controlling the authentication? Normally done by the IdP at the request of the RP.
I really cannot see the benefit for the user in what you are proposing, you are essentially taking away their point of control and making the whole thing RP centric.
One last thing...identity ecosystems need to have balanced trust between all parties for them to work, this is especially true in consumer systems where your user base is much less under your control and need to buy into the idea of your community. It's this delicate balance that I believe your proposed system would disrupt
Stephen: I have never yet seen a suggestion that is better than the IdP model *in practice*:
A modern IdP does not have to request “excessive PII” – users can add attributes when and as required. However, a fundamental component of an IdP is user verification, enabling the identities it supplies to have a quantifiable trust; without verification, attributes are worthless. Verification requires disclosure of personal information.
You say “why should I disclose excessive PII to a new IdP only to have them reveal just my age to an RP?”. Can you explain then how you are going to identify yourself to an attribute provider without first having to supply to it all of the personal data required to verify your identity to it?
And repeat that for every attribute provider that you need to use. That’s, potentially, a lot of effort to ask of a user. And that’s assuming attribute providers have the desire / ability / relationships to verify individuals, for online attribute requests, which, in my experience, they often don’t.
Also, how do you address the issuance of the token from each attribute provider? Is this a long-term token that the user will have the responsibility for storing, ensuring availability on each device, etc? (Users aren’t good at this.) How will the user get another token from the attribute provider? (Presumably, the user will be required to identify themselves in some way?)
Overall, I cannot see that a direct relationship between RPs and attribute providers does anything but shift around the issues, rather than improving anything.
Finally, I think a problem with your thesis is that it’s predicated on the idea that RPs perform identification of a user. I think it’s better to say that they assume identity, based on whatever information is supplied to them.
Steve Hitchen: what IdP model is there in *in practice*? Are there any general purpose IdPs actually doing what you and Susan envisage? Or are they still on the drawing board? These things are easier said than done. Getting RPs' lawyers to accept Ts&Cs for novel IdPs is what stopped the Internet Industry Association's 2FA pilot, and it's actually what stopped Big PKI. Watch out for the fine print in any new IdP contract!
Maybe we're on a different wavelength as to "attributes". I am talking about the stock and trade of business authentication: things like age, address, legal name, professional qualification, registration numbers, employment status, company position, bank account number, credit card number, student number, health identifier, insurance policy number etc etc. These factoids are today issued by respective recognised authorities under all sorts of rules and processes, the details of which are available if we want to investigate, but very rarely actually examined. We take it for granted that various Institutes of Chartered Accountants issue credentials to accountants, health authorities issue practicing licenses to doctors, the Arkansas DMV issues driver licenses to people in that state, and so on.
Now the question of identification at the AP ... it's a red herring. Consider that if someone presents me with an Arkansas driver license, I can rely on that as an assertion of the holder's age. But I don't know how the Arkansas DMV identifies its license holders before issuing the license. In fact I don't even know how the New South Wales license body identified *me* for my own license, it was so long ago.
The process of identifying the subject of an attribute is a matter for the AP. We can (and must) treat the identification process of an AP as just one element of the overall attribute issuing process; we don't really care how identification is done at professional bodies, universities, employers etc etc; we trust it is fit for purpose.
So my vision is that we equip today's recognised APs with the means to simply issue robust digital versions of their existing credentials. And that end users carry those digital credentials in digital wallets (or leather wallets in the case of chip cards). In many cases the existing supply chain for issuing cards can continue unchanged; in other cases, some minor changes will allow standard attributes to be issued to users' smart phones. I am not proposing that people run around looking for umpteen new APs, nor that RPs have to understand any new APs. All the important attributes in routine business are already provided by extant bodies. No new arrangements are needed.
Nice post Steve, there are likely some basic categories or dimensions here besides traditional assurance and confidence, e.g. timeliness, fit for use. Attribute Rex..
I've designed and seen implemented consumer facing (as opposed to enterprise) IdPs of exactly the type that Susan describes; one of these was designed to be used by those with a reading age of 9, so I can say with some confidence that this model is available and does work in practice.
The idea of direct RP to AP is not new; at initial stage design sessions that I’ve attended this model has frequently been proposed and rejected by people far more erudite than me.
Rejection has been due partly to the issues that arise when such a scheme is examined in detail from an implementation perspective; the following are *some* of the issues raised:
Difficulties in establishing one to many relationships between RP to APs.
APS that are currently ‘online’ tend to supply their data via SOAP interfaces that are relatively easy to secure and control access to; if an AP was to expose their interfaces to a range of RPs, this becomes a much bigger problem for them. For an end user to authorise the release of attribute data or obtain a token implies some sort of OAuth type access, or user sign into the AP. This has significant security implications for an AP, as the AP now has a web UI to secure, which is orders of magnitude more complex than securing a SOAP service.
There is no standardisation across APs, in terms of access, data formats, etc.
Usability – The RP-AP system was considered to be confusing to users, especially those with little IT experience. Also, can such users be expected to manage tokens - conceptually difficult?
AP data security: In some cases APs are not willing to supply data directly to RPs where there isn’t a strong trust relationship. However, supplying data to a limited number of IdPs where a strong trust relationship can be developed and managed is more acceptable. The IdP can then be trusted to use the attribute data and then release it to an RP in a masked, or otherwise modified form, so that the original data isn’t exposed. One simple example of this is a dynamic CML rating.
AP availability: Some AP data isn’t in a form that can be readily used by RPs. A well-known example in Europe is the SuisseID system. This is based on the electronic identities issued to Swiss citizens in the form of PKI-based hardware tokens. The difficulty in using client certificate authentication to an average RP is also well-known, so the Swiss government exposed the user’s data, stored at the CA, through ha standard SAML 2.0 IdP. This had the advantage of making it relatively easy to access by RPs and assuring users of data privacy, through controlled release of attributes – something not possible if the token was used for client certificate authentication to a website.
Bringing privacy into the front (for Malcolm’s benefit), an IdP acts as an isolation point between the RP and AP data, and can control the release of user data in a very granular manner, so enhancing privacy. For example, an IdP can be configured to only release date of birth information in forms such as ‘under 18’ or ‘over 65’ etc. Having a single point (IdP) for a user to control this is highly effective in addressing privacy issues.
I could go on, but I think you get my point that RP-AP is not something that people haven’t considered before, at length, with the consensus that RP-IdP may not be perfect but is the better choice, at least for the present, unless there is an overwhelming case for the former based on real evidence.
- Do you have a reference please for the IdP system designed for low reading age users?
- What services does it support?
- Is it LOA 3 or 4?
- Who was it that "considered" RP-AP systems "confusing"?
- If users have little IT experience, how is dealing with a new IdP less confusing than say dealing with your employer, university, DMV or government agency (the actual APs I've been talking about)?
- At high LOA, I've never understood how users are envisaged to make a decision between IdPs.
- Why are tokens conceptually difficult?
To me there are two overarching points Stephen makes that I think show why the concept of identity providers is flawed:
Identity is in the eyes of the RP:
Trying to represent "identity" via an "identity provider" assumes that the subject is simply a collection of attributes. However to one RP I'm simply "verified as over 18," to another I'm a resident of a particular state and to another I say I'm a 3rd level warrior elf. Which leads me to my second point.
The RP needs to do identity verification in some cases:
For example who can verify that I really am a 3rd level warrior elf except the RP that bestowed the honor? Also try telling a financial institution to trust an "identity provider" to assert that the attributes it provides really do represent the person using the device.
An individual should be able to collect and store her attributes. She should be able to validate some of them through and agent/authority and an RP should be able to ask me for them and choose to validate them or not. That requires cryptography not a system that stores all my personal data and encourages me to define myself in terms of it.
I'm afraid that, due to contractual and political restrictions, I can only be sketchy about that system.
The services (I'm assuming we're talking about RPs -I may have picked that up wrongly) are related to applications for educational courses, grants, storing of CVs, and related.
The IdP provides is a single, familiar point of access, which with SSO, does make use (relatively) easy.
The question about users selecting an IdP is an interesting one (although it doesn't yet apply to the above, as there isn't a choice), and usability testing has revealed some unexpected reactions from the public about who they trust, implied cost, etc. Most people go seem to prefer either an IdP associated with something they already have a close relationship with (e.g. their own bank, a supermarket or telecoms provider) or a familiar and trusted national institution that isn't directly connected with the government, such as a postal service.
The reason why tokens are conceptually problematic (and this applies to Adam's comment) is that, unlike bank cards, identity cards, etc., they aren't real and this totally confuses a surprising number of people.
I have to say, I did find this surprising, but when you realise that most people (even if they use computers for work or eBay, etc.) go blank when they are told (on-screen, and without the aid of someone patiently explaining it to them) that they may have to store and manage some token (a term that means nothing to them), potentially across several devices. You then realise that it's probably not going to work for mass market use, where lowest common denominator is the common requirement.
Adam re: RP verification. If a financial institution can't trust the IdP then it certainly can't trust an attribute provider - the same trust relationships apply to both: the bank can either trust the IdP to assure the identity of the person using the device (and it can have a say in the level of this assurance when it requests the authentication) or it can trust that the user really is authorised to use the AP's token. No real difference?
Adam's final statement, regarding storing attributes, is certainly an interesting one, that's increasingly being examined from a wide range of perspectives. One, that some are exploring, is the concept of a personal IdP / data store. Again, however, these concerns are often way beyond most people - just look at the amount of personal data entrusted to Facebook, etc...
Steven, it's a shame isn't it that your best examples of IdPs cannot be described in detail? As set out in my CIS Napa paper, time after time, classical IdPs (and before them Big CAs) have failed because of the fine print attached to the "identities" they provide. The value proposition is killed by either the additional policy mapping and legal investigation required by RPs, or the extra effort required to 'top up' the IdP's "identity" with extra attributes germane to the RP. If we cannot see the Ts&Cs of the allegedly successful IdPs, then it's not a real counterargument.
I don't think we're even getting warm. If the IdP you're referring to is actually compulsory, it's not quite the sort of IdP envisaged by open identity ecosystems like NSTIC.
I disagree that "the IdP is dead", but I may have a different view of an IdP. I agree with Andrew that "attributes are at least as interesting" but we still need something that acts on behalf of the subject.
Because of the inter-sector complexities you describe, APs may operate primarily within specific sectors. But something as generic as authentication should be able to operate cross sector; we are hoping to avoid the need to have different authentication tokens for healthcare, financial services, employment, etc. An IdP also needs to manage multiple tokens that a user may possess, allowing them to be enrolled when needed and revoked when lost or stolen. Absent an IdP, a user would need to manually perform these operations at each RP where they're used, which is burden on the RP but especially on the user in the event of loss or theft.
Another function for an IdP might be to help an RP locate trustable assertions about the user. I described this role in a presentation I put together a few years ago ( http://www.slideshare.net/jim_fenton/identity-systems-8537393 slide 21-23) where the IdP helped an RP find an attribute source with the appropriate trust characteristics. The IdP can (and does in this example) also provide some isolation between the attribute source and the RP, which may have some privacy benefits.
I have seen several of these "bare token" authentication schemes emerge recently, but they don't seem to be considering the real-world problems of revocation and the like. If there's a problem that needs to be solved regarding IdPs, it is that they mustn't try to do too much in the attributes area lest they become too sector-specific.
Thanks Jim. I do agree with your assessment of the pain points. You hint that we might have slightly different angles on "IdPs". I wonder if the important functions you describe for an "IdP" is more about being an 'authentication helper' than a provider of identity/ies?
However I don't agree that authentication is "generic". If you mean we have a common generalised identity across multiple contexts, then I suggest that may be something of a false intuition. I have the same handle "Stephen Wilson" at various banks, government services, businesses and so on, but they all these SPs/RPs know me in different ways. To take a specific example, the "Stephen Wilson" who operates a personal bank account is not legally the same "Stephen Wilson" who operates a business bank account (even at the same institution).
My identity means different things to different RPs. Especially at higher LOAs, we are probably stuck with a floor number of disparate identities.
So what to do about usability? I suspect our hunger to federate would not be so urgent if authenticators were simply easier to use. If we moved to digital wallets on smart phones, and if we carried more online-accessible smartcards in our leather wallets, then I think we'd be quite comfortable continuing to operate 10-15 or more separate identities.