![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
For my friends who are interested in the nymwars and the US government's National Strategy on Trusted Identities in Cyberspace (NSTIC), this is a long post that hopes to establish how the technical term "Identity Provider" is a little different from establishing an online Identity.
It's late, i've left out lots, but there's lots of detail, that i think if you don't understand how the SAML Identity Provider technology works, you may misread in some technical discussion.
I (with my colleagues) am building an "IDP," an IDentity Provider service. I want to explain how it works. You may already use systems like this -- or at least systems that have been built with the capabilities to work this way. An organization may use the system just to tie a whole bunch of legacy applications together. My health insurance uses a system like this to bridge between their pharmacy units and some other units (i can tell by watching the URL address bars bounce around), but my health care provider gives me both the IDP and the services: i can't use my own IDP to get access to those services.
The NSTIC -- NAtional Strategy for Trusted Identities in Cyberspace -- could change things so i would need a new username and password with my HMO.
I'm building an IDP that libraries use to provide services for their patrons. The libraries have actually verified the identity of the patrons. In some cases the verification is pretty extensive: consider Angel Alvarez, faculty member, at State U. There's probably someone who has looked at Angel, looked at a government ID, and called up a couple of references before Angel was set up with an IDP account. There's also moderately verified identities: Barb Brodsky had to show a government ID and a utility bill before getting a library card at The Town Library.
NSTIC codifies levels of verification. There's the strong level of verification that a library may have done, a lower level of verification in most relationships that are established over the phone or net with a credit card, and a much lower level of verification in self asserted identities at places like Facebook, LinkedIn, etc.
So the identity provider has some codifiable level of verification that A or B are persons, and the IPD then gives A & B a way that they can prove over the internet that A is really A and B is really B. Often this is just a username and password, but there are other ways to have credentials.
Now, in the systems of IDPs that i'm building, those credentials are essentially a secret between A & B and the Identity Provider. No one else should ever see their user name and password.
Along comes another service. The services i'm mostly involved with are services like academic journals and database providers, so call this JournalWorld. They want to sell their services to the institutions who will buy those services on behalf of their patrons. But the resource providers want to have a relationship with Angel and Barb, in the sense that they want to be able to keep a list of Barb's interests or a bibliography on behalf of Angel.
The Identity Provider at Town Library configures their system so that whenever JournalWorld bounces a user to the IDP for authentication, the system will give a unique identifier back to JournalWorld. The Identity Provider at State U is a bit more sophisticated: they have an interface where Angel can configure a shared email address that could be different for the email address he uses for his university email. The first time Angel is authenticated with JournalWorld he gets a page that lets him choose "claims" that State U will share with JournalWorld. He can allow StateU to tell JournalWorld he's DoctorDanger as a "greeting name" and to let JournalWorld know his shared email address. Because of the contract though, the IDP is going to tell JournalWorld that Angel is a faculty member: that way Angel can reach all the expensive resources that the the university bought for faculty in the Ag department. If the IDP didn't provide that claim, Angel would just see the limited group of US journals. If Angel allows the optional claims to be made JournalWorld then can then send Angel email whenever his saved search on risk management in milk supplies has a hit. JournalWorld can still ask Barb for a name to greet her with and for an email: they just associate it with the ID provided by Town Library.
The neat thing about these SAML systems is that they can give JournalJungle a completely different identifier. If someone got the logs at JournalJungle and compared them to those at JournalWorld the IDP would not made it possible to link the two uses. (Of course, Angel could have told both systems he was DoctorDanger and so it wouldn't have mattered.)
This is what SAML and Shibboleth systems do *now*: they're privacy aware, and they're designed to allow a trusted organization to assert claims about a user to a specific other party, there's some awkward user experience that allows users to control some of the claims that are made.
There are some really neat possibilites here. Let's say Town Library decides it wants to be an Identity Provider. They'd let Barb know and they might offer Barb the ability to come in and establish her age. Town Library then registers with some organization that they can provide up to a level 2 verification of age, address, and name for their users.
Now could Barb use this IDP with her HMO? Probably not an employer provided HMO, but if Barb was self employed and bought her own health care, she might start by visiting the HMO webpage and indicating she wants to use Town Library to log in. When she does so, the tells Town Library IDP to make the claims of her age, address, and name. It's possible HMO might tell Town Library that they won't accept a login without those claims verified to a certain level. Barb doesn't need to set up a new username and password with the HMO: whenever she wants to log in, she's bounced to Town Library, proves she's herself there, and then bounces back with claims to the HMO.
Barb wants to make some comments to her local legislator, anonymously. Her legislator wants to hear the complaints, but also wants to be sure commenters are constituents and not generated by some lobbing group. Barb goes to Representative Critter's web page and says she wants to login via Town Library. This time, Barb tells town library to ONLY tell Rep Critter her zipcode -- and keep her identity anonymous. This time, Town Library only claims that Barb is from zipcode 99999 -- and Town Library doesn't even provide a unique identifier for Barb. The next time Barb wants to provide an anonymous comment, all Representative Critter knows is that another resident of the 99999 zip who uses Town Library as an IDP has commented.
Barb also wants to start hanging out at a Slash-Is-Us social network. She selects Town Library as an IDP and indicates she wants a pseudonymous login with an age claim. Slash-Is-Us is comforted to know that the user is verified as over 21 and lets Barb set up her GoldenGoose identity. When Slash-Is-Us is hacked they can find that GoldenGoose is over 21 and is identified by a long cryptic code from TownLibrary. There's no way that her identity at Slash-Is-Us can be linked to her HMO: she didn't have to tell Slash-Is-Us her birthdate.
Now Barb may really think of Slash-Is-Us as where she's established an identity. Slash-Is-Us may provide an OpenID that she uses to comment on other blogs, and it may be where her friends know her, and it may be where she journals her life. GoldenGoose may be her Identity; Town Library is trusted party with whom she shares credentials to establish that it is her, Barb Brodsky, logged into a particular browser on a laptop in a coffee shop, initiating activity across the web.
The gap today is that for a resource provider to trust an IDP, they have to have a relationship. Town Library might have motivation to establish a relationship with Rep Critter, but would they take the time to set up with Slash-Is-Us? With more infrastructure, registries could be set up, where IDPs can establish (and be audited) on how well they verify identities and where Relying Parties can establish their trustworthiness in receiving the data. That's a part of what NSTIC is about.
Can google play in this space? Well they *could* have, but they really aren't playing WELL.
Note there's NOTHING in the description of interactions above about Town Library forcing Barb to have a public profile. Nothing about forcing Barb to share her name with anyone.
It's late, i've left out lots, but there's lots of detail, that i think if you don't understand how the SAML Identity Provider technology works, you may misread in some technical discussion.
I (with my colleagues) am building an "IDP," an IDentity Provider service. I want to explain how it works. You may already use systems like this -- or at least systems that have been built with the capabilities to work this way. An organization may use the system just to tie a whole bunch of legacy applications together. My health insurance uses a system like this to bridge between their pharmacy units and some other units (i can tell by watching the URL address bars bounce around), but my health care provider gives me both the IDP and the services: i can't use my own IDP to get access to those services.
The NSTIC -- NAtional Strategy for Trusted Identities in Cyberspace -- could change things so i would need a new username and password with my HMO.
I'm building an IDP that libraries use to provide services for their patrons. The libraries have actually verified the identity of the patrons. In some cases the verification is pretty extensive: consider Angel Alvarez, faculty member, at State U. There's probably someone who has looked at Angel, looked at a government ID, and called up a couple of references before Angel was set up with an IDP account. There's also moderately verified identities: Barb Brodsky had to show a government ID and a utility bill before getting a library card at The Town Library.
NSTIC codifies levels of verification. There's the strong level of verification that a library may have done, a lower level of verification in most relationships that are established over the phone or net with a credit card, and a much lower level of verification in self asserted identities at places like Facebook, LinkedIn, etc.
So the identity provider has some codifiable level of verification that A or B are persons, and the IPD then gives A & B a way that they can prove over the internet that A is really A and B is really B. Often this is just a username and password, but there are other ways to have credentials.
Now, in the systems of IDPs that i'm building, those credentials are essentially a secret between A & B and the Identity Provider. No one else should ever see their user name and password.
Along comes another service. The services i'm mostly involved with are services like academic journals and database providers, so call this JournalWorld. They want to sell their services to the institutions who will buy those services on behalf of their patrons. But the resource providers want to have a relationship with Angel and Barb, in the sense that they want to be able to keep a list of Barb's interests or a bibliography on behalf of Angel.
The Identity Provider at Town Library configures their system so that whenever JournalWorld bounces a user to the IDP for authentication, the system will give a unique identifier back to JournalWorld. The Identity Provider at State U is a bit more sophisticated: they have an interface where Angel can configure a shared email address that could be different for the email address he uses for his university email. The first time Angel is authenticated with JournalWorld he gets a page that lets him choose "claims" that State U will share with JournalWorld. He can allow StateU to tell JournalWorld he's DoctorDanger as a "greeting name" and to let JournalWorld know his shared email address. Because of the contract though, the IDP is going to tell JournalWorld that Angel is a faculty member: that way Angel can reach all the expensive resources that the the university bought for faculty in the Ag department. If the IDP didn't provide that claim, Angel would just see the limited group of US journals. If Angel allows the optional claims to be made JournalWorld then can then send Angel email whenever his saved search on risk management in milk supplies has a hit. JournalWorld can still ask Barb for a name to greet her with and for an email: they just associate it with the ID provided by Town Library.
The neat thing about these SAML systems is that they can give JournalJungle a completely different identifier. If someone got the logs at JournalJungle and compared them to those at JournalWorld the IDP would not made it possible to link the two uses. (Of course, Angel could have told both systems he was DoctorDanger and so it wouldn't have mattered.)
This is what SAML and Shibboleth systems do *now*: they're privacy aware, and they're designed to allow a trusted organization to assert claims about a user to a specific other party, there's some awkward user experience that allows users to control some of the claims that are made.
There are some really neat possibilites here. Let's say Town Library decides it wants to be an Identity Provider. They'd let Barb know and they might offer Barb the ability to come in and establish her age. Town Library then registers with some organization that they can provide up to a level 2 verification of age, address, and name for their users.
Now could Barb use this IDP with her HMO? Probably not an employer provided HMO, but if Barb was self employed and bought her own health care, she might start by visiting the HMO webpage and indicating she wants to use Town Library to log in. When she does so, the tells Town Library IDP to make the claims of her age, address, and name. It's possible HMO might tell Town Library that they won't accept a login without those claims verified to a certain level. Barb doesn't need to set up a new username and password with the HMO: whenever she wants to log in, she's bounced to Town Library, proves she's herself there, and then bounces back with claims to the HMO.
Barb wants to make some comments to her local legislator, anonymously. Her legislator wants to hear the complaints, but also wants to be sure commenters are constituents and not generated by some lobbing group. Barb goes to Representative Critter's web page and says she wants to login via Town Library. This time, Barb tells town library to ONLY tell Rep Critter her zipcode -- and keep her identity anonymous. This time, Town Library only claims that Barb is from zipcode 99999 -- and Town Library doesn't even provide a unique identifier for Barb. The next time Barb wants to provide an anonymous comment, all Representative Critter knows is that another resident of the 99999 zip who uses Town Library as an IDP has commented.
Barb also wants to start hanging out at a Slash-Is-Us social network. She selects Town Library as an IDP and indicates she wants a pseudonymous login with an age claim. Slash-Is-Us is comforted to know that the user is verified as over 21 and lets Barb set up her GoldenGoose identity. When Slash-Is-Us is hacked they can find that GoldenGoose is over 21 and is identified by a long cryptic code from TownLibrary. There's no way that her identity at Slash-Is-Us can be linked to her HMO: she didn't have to tell Slash-Is-Us her birthdate.
Now Barb may really think of Slash-Is-Us as where she's established an identity. Slash-Is-Us may provide an OpenID that she uses to comment on other blogs, and it may be where her friends know her, and it may be where she journals her life. GoldenGoose may be her Identity; Town Library is trusted party with whom she shares credentials to establish that it is her, Barb Brodsky, logged into a particular browser on a laptop in a coffee shop, initiating activity across the web.
The gap today is that for a resource provider to trust an IDP, they have to have a relationship. Town Library might have motivation to establish a relationship with Rep Critter, but would they take the time to set up with Slash-Is-Us? With more infrastructure, registries could be set up, where IDPs can establish (and be audited) on how well they verify identities and where Relying Parties can establish their trustworthiness in receiving the data. That's a part of what NSTIC is about.
Can google play in this space? Well they *could* have, but they really aren't playing WELL.
Note there's NOTHING in the description of interactions above about Town Library forcing Barb to have a public profile. Nothing about forcing Barb to share her name with anyone.