Identity Standards: The Soap Opera (catch up on previous episodes + review major plot points

From IIW

Identity Standards: The SOAP OPERA Catch Up On Previous Episodes & Review Major Plot Points


Wednesday 6H


Convener: Pamela Dingle


Notes-taker(s): Heather Vescent & Scott Mace


Tags for the session - technology discussed/ideas considered:


Identity Standards



Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:


1. Notes from Heather Vescent:

  1. Kerberos
    1. Mid-90s
    2. Symmetric key management
    3. The only identity was the principle – the name of the account
    4. To do identity for machines, and people in labs, and with cross signing K, it started to look like federation. Large scale interfederation, as late as early 20s.
    5. Useful within a domain?
    6. You couldn’t control information flow.
    7. You shared everything or nothing.
    8. Perimeter security. Lab security measurement.
    9. Lack of granular AuthZ
    10. Microsoft had an embrace and extend philosophy, that caused issues. (true/false)
    11. MIT implementation of K, but they were lazy and couldn’t keep up (the real story/drama)
    12. Where there is a natural perimeter, K still works.
    13. Spinago
    14. Thought you could do everything with symmetric crypto.
  2. Directories – late 90s
    1. LDAP (x506)
    2. A whole bunch of machines, separately authenticated to, managing passwords.
    3. A central place to store identity information, and validate passwords
    4. Make calls to a central location.
    5. Soap opera: Novell, MS and Netscape – directory was very popular. Active Directory started working.
    6. ADSI – was alternate to LDAP
    7. There was the MS way, and LDAP
    8. Dale Olds, was a prime chief architect in ADS-LDAP
    9. Mark Wall – wrote the book
    10. Roland Hedberg – chair
    11. Federation scheme involving LDAP
    12. Every perimeter had a directory in the middle
    13. Directories are the world of LANs
    14. Extranet was popular – going out was the exception
  3. Web Access Management
    1. Siteminder/Oblix
    2. Late-90s, early 00s
    3. People wanted to use LDAP, but needed enforcement of consistent access
    4. Popularize the concept of agents.
    5. Agent would sit on the web resource, and enforce/gatekeeper, if no credentials, redirected to a central service.
    6. Domain limited, encrypted cookie, authorization information, and worked with agents who would redirect
    7. LDAP isn’t a good authentication method, so needed to abstract.
    8. The agent is sitting in front of the website, (not at the user try to access)
    9. Apache module or ISAP, NSAPy plug-in.
    10. Siteminder, was first offering, central administration of their websites and was very popular
    11. Oblix – Oracle
    12. This wasn’t enough because of cookie based domain based way they did authorization and access management
    13. Single tenet on-tem, inside the corporate firewall.
  4. Federation
    1. SAML/Liberty Alliance
    2. WS*
    3. Pam’s first conference – Burton Group, MS announced project hailstorm
    4. MS was offering to authenticate everyone – people were terrified that the world would be owned by one centralized company.
    5. Saw a lot of people yelling at each other, the Liberty Alliance was formed by companies with the paradigm that no one company should run anything.
    6. Liberty Alliance: Can not be owned by Microsoft. To contain the MS agenda.
    7. SAML came out of Liberty Alliance. Every company wanted their own stuff.
    8. Scott Canter
    9. Tony Nadelin
    10. Eve Maler
    11. Jeff Hodges
    12. These are the gas giants, they still make up the mass of the universe.
    13. Sun Microsystems
    14. SAML is being negociated. It’s nacent. But the cloud is just starting to be a real thing.
    15. They want to federate in themselves, and among their partners. Finding more new use cases.
    16. Single Sign on became a buzzword with SAML
    17. Identity Provider also became a buzzword
    18. All big companies driving in a closed spec work.
    19. A new generation of people wanting to do identity their way, and own their own identity. This was the rise of OpenID.
  5. OpenID
    1. Not started as a specification, but the implementation of an idea – PHP on live journal.
    2. It fit an interesting niche in a way that SAML didn’t
    3. It was all about ad-hoc identity, run your server. Johannes Ernst\Dave Reecordan
    4. We weren’t good at the signing and leaking issues
    5. SAML had canonization
    6. First OPENID protocol, new redirects and could fool the system and it iterated
    7. Came up with OpenID 2.0, which worked well
    8. Mobile occurred – 2007
    9. Mobile apps that wanted to consume identity, and these clients were impersonating people to tweet for them
  6. Delegated Auth2
    1. OAuth 1.0
      1. This came about as a way to delegate id to an API
    2. WRAP
    3. Kerb Constrained Delegation
    4. Web, then mobile
    5. API driven
    6. Before we didn’t write website with APIs
    7. Could do openID and
  7. Infocard – pre-mobile
    1. Most influential failed standard
    2. You should be able to have a wallet, and put a card in the wallet with the identities and credentials.
    3. No mobile
    4. WS* and secure, WS trust specifications
    5. First driven by MS and mostly about the browser, increasing need to make remote procedure calls, APIs, desktop and server to server. You had secure this.
    6. WS* system, based on API calls using SOAP, XML
    7. You can not tell a lie on the security of a channel.
    8. Complicated system for doing crypto, message based
    9. Industry participants: MS, Sun, IBM
    10. This has a lot of properties we are trying to bring back today
    11. This was a high complexity down payment.
    12. Provided the basis of information card, which didn’t live inside of a browser.
    13. Ask any 5 people why it failed, you get 5 answers.
    14. Biggest issue for relying parties is you were out of control.
    15. Loss of control – FAPI world
    16. DID Com is around message based security.
    17. Pam D, Vittorio, Kim Cameron
    18. Loss of control – SAML branch that figured out how to mitigate that – Trust framework. Walled garden with 10k IDPs, Governance.
  8. Oauth2 + OpenID Connect
    1. Huge and growing number of specifications
    2. UMA
    3. OPEN ID foundation – founded by Don Tibeau,
    4. WRAP was next gen of OAUTH 1.0 could evolve
    5. Cloud providers wanted things to be easy for developers – secure, but easy.
    6. Enterprise folks, who wanted enterprise grade for an enterprise audience
    7. Reaction to people’s experiences with SAML, OAuth 1.0, WS* - so this was the reaction to the past.
    8. One of the big players, threw down his bat and went home – it was a scandal. Eron Hammer.
    9. The inventor says its bad.
    10. But then things got smoother – oauth 2. Formalized to the identity of the client (the user and the identity of the client working on behalf of the user – the client gets its own secret/token – reintroduced symmetric crypt.
    11. People wanted to use oauth 2 for identity – but only enables a client to ask for a token to act on behalf of a user.
    12. OpenID Connect evolved to fill that. To ask for the identity of the client and use access tokens. It took browser flows, and explained how to request certified id and access token. Claim and description of the access moment.
    13. We gained a ton of stability. Season ended on a high note.
    14. Learnings: SAML was an 800 page spec, Liberty Alliance thought of every single use case, still stuff no one uses, because it was so thougrough, and very heavy. SAML is about sophisticated party talking to a sophisticated party.
    15. OAUTH2 is assymetic model, can have a sophisticated party talking to unsophisticated client, important for mobile. Eg secrets kept on mobile apps.
  9. Decentralized Identity
    1. DID
    2. VC
    3. DID*
    4. Key management
    5. Canonialization
    6. What did this inherit from previous points?
    7. We are writing it now. What in the history do we need to look at? What are the other pieces that we should write down here.
    8. What were the security implications along the line that should be accounted for in DPKI. Looking at APTs and how they interacted with building, to force us to reinvent.
      1. Key/ Signature wrapping – this is why people are concerned by JSON-LD
      2. Had a lot of vulns because someone did it wrong in implementation
      3. The systems stopped working, so someone turned off signature checking, and it all worked, so feels like it’s not a problem
      4. There are tons of SAML deployments, where they turn off key. Verification or signature – we have a massive problem how to verify the signature of meta data with it turned off.
    9. Nascar – 5 identity provides you accept identity assertions
    10. Large number of UX/ security issues/phishing attacks
    11. We figured out how to deal with crypto aspects – crypto got better/solved up to 6, but UX has left. UX from the developer perspective.
    12. Pick any of the SSI demos that exist today, look at those demos from the eyes from someone who isn’t familiar with technology, and see where these can be phished.
    13. Multi-Card



What about FIDO?

  • Could be its own chapter
  • It’s not identity
  • Mechanism for carrying credential



What about PKI?


*********** *************** ********************** ******************* *************


2. Notes from Scott Mace:


7 phases of the soap opera


Kerberos was first

  1. Directories and LDAP – 1995 to present
  2. Web access management
  3. Federation
  4. Delegated authorization
  5. InfoCard
  6. OAuth 2 & Open ID Connect
  7. Decentralized – today’s episode


Q: So this is as the identity turns, episodes 1-7


MIT vs Microsoft Kerberos alone could take up the whole time


LDAP evolved from pain around X.500

Web access management was cookie-based access management. SiteMinder put Web management in front of directory-enabled resources. Oblix.


This is totally collaborative. Don’t take it as gospel.


Was also SAML Liberty Alliance timeframe. Also WS*. WS* goes all the way down to Infocard.


Delegated authorization is Oauth 1.0. Not like it just appeared and didn’t exist before that.


Q: Plus WRAP


Q: They were a main character in the episode.


Constrained delegation


Q: Air gap security.


Open ID is between 3 and 4.


InfoCard is its crazy little spinoff.


Oauth 2 & Open ID Connect are huge, many spinoffs.


Decentralized – DID/VC/DID-*


Q: Map these standards under different organizations and communities.


Dramatis personae.


Q: Game of Thrones families.


Those are part of the stories. Important for new folks to understand why these efforts occurred.


Q: What did #7 inherit from 1-6?


A good point.


Q: Does FIDO fit anywhere into this?


Scott Mace: How about UMA?


Pamela put UMA under #6.


FIDO may be its own story.


Q: People still use X.509 for identity, but nobody will probably use Webauth for identity.


Q: Kerberos was identity for machines in labs and people. People were looking at large-scale integration of Kerberos realms.


Why did Kerberos not then jump domains?


Q: You couldn’t control information flow with Kerberos. Very little specific detailed control. Even today you won’t find many AD control points exposed to the Internet. Perimeter security. MIT Kerberos team was lazy, couldn’t keep up. The Apple team, Heimdall, was able to keep up with MS.


Q: There was a lawsuit that MS lost.


Q: There are browser plug-ins that do in-house Kerberos sign-in today.


Q: The lost part of Kerberos that was interesting was HTTP authentication. Nothing ended up in #7. Kerberos thought you could do everything with symmetric crypto. Everything is key management. All hard problems in security can be reduce to hard problems in key management.


Diretories. Silos of machines everywhere. LDAP gives you a central place to store identity information but also to validate passwords. Tension between Microsoft and LDAP. Also ADSI.


Q: Windows for Workgroups in early directory land?


Q: Novell NDS was essentially X.500.


Dale Olds was here yesterday. Trying to turn X.500 into LDAP. The other one not here is Mark Wall. Roland Hedberg.


Q: There was also a federation scheme involving LDAP.


Q: There was a project with Patrick Helstrom and Leslie Dagel to build a directory of directories type federation. A way to rebuild whois.


Q: What time was this happening?


Q: Late 1990s. While mobile incumbents were being split up. Had to deal with number portability.


Q: I worked with screening service in 2000, the original multiple signon with AOL and Microsoft. It failed.


Q: Didn’t have anything to do with login, necessarily.


Directories were perimeter limited. Part of the chewy center. Not an internet-grade mechanism.


Q: Directories are the worlds of LANs.


Leads to web access management. LDAP needed the enforcement that came with consistent web access. Web access management popularized this concept of agents, the most overused word in identity. Agents were gatekeepers. Without proper auth, would redirect you to a central service. It was an encrypted cookie that contained auto info, agents that redirected to the center.


Q: LDAP isn’t a good authentication method.


I agree with that.


Q: The agent here is sitting in front of the web site being protected, not on the user’s system.


That tended to be an Apache model, or an ISAPI plug-in. SiteMinder really set this whole thing off. Offered enterprises to centrally administer all their web sites. Oblix came on the heels. SiteMinder went to CA, Oblix to Oracle, still there. But wasn’t enough due to the cookie-based and domain-based way they did authorization.


Q: Set the stage for the next stage, which was SAML.


Cloud didn’t exist. This was late 1990s until early 2000s.


The federation piece. I will tell you a story. Went to BG Catalyst in 2001, MS announced Project Hailstorm. Offering to authenticate everyone. People were terrified, that the whole world would end up centralized and owned by one corporation.


Scott: Hailstorm was one of MS’ responses to the Internet.


Liberty Alliance was the idea of no one company should run everything.


Q: Had to be part of the elite to sit at the table. It was to contain MS.


SAML came out of Liberty Alliance. Every company wanted their own autonomy and make its own assertions.


Q: Scott Kantor turned SAML into something that actually worked. He put in a shim and made a serious thing of it.


Tony Matlin played a role. Eve Maler. Jeff Hodges. A lot of these people are still around.


Q: In the solar system of identity, these are the gas giants.


SAML is gaining support, still nascent, but the cloud is starting to become a real thing. They don’t just want to federate with their business partners, they want to federate amongst themselves. 2002-2006. People finding new use cases.


Q: When did SSO become a buzzword?


Q: SAML.


It was all big companies, a closed spec work. There was a new generation of people who wanted to do identity their way and own their own identity. The rise of Open ID. The federation stuff is pre-existing trust. But cloud providers were evolving. Folks like Twitter.


Q: Movable Type. Identity for blogs and comments. That’s how I got into it.


Justin: Original Open ID was not started as a spec. It was an implementation of an idea, in PHP on LiveJournal. Use your blog to comment on someone else’s blog. Fit an interesting niche in a way SAML did.


Q: It was about ad hoc identity.


All based on URLs. Assert things around your URL in your bedroom.


Q: Johannes Ernst is still here. And Dave Recordon.


Unfortunately the signing and leakage issues, SAML people had problems with canonicalization. The first Open ID protocol, could add additional query parameters to the connects. Open ID 2.0 became quite popular. However at same time this was stabilizing, OAuth 1.0 came out. Mobile occurred around here. 2007. Mobile apps were asking for people’s username and password, and replaying those, a massive antipattern, massive fraud, because there was no alternative. OAuth 1.0 was a way to delegate capabilities.


Web, then mobile.


Q: But API driven is the key point. Before this we didn’t build Web sites with APIs as a major thing. Couldn’t do that much with them. People were building Web sites with an API that were a front end to that API.


Stuff joined Open ID and OAuth together.


Q: That was a disaster.


Information Cards, most influential failed standards effort. Have a wallet, put cards in wallet that rep the ID and attributes you own and control. This was before mobile. 2006.


Q: People couldn’t convince the browser manufacturers to implement it.


Was based on WS*, WS Trust.


Vittorio: My license plate was WS*. SAML was driven by MS, mostly about the browser. Increasing needs for RPCs. No way of doing that apart from Kerberos. Based on SOAP. Very complicated system for doing crypto, doing things message based rather than transaction (?? Session ??) based. Sun and others did it. It asked everyone to put down a high down payment in terms of complexity. Huge adopting in MS but also floundered. Info Card was an active client in the OS.


I wrote a lot of open source RP code for WordPress etc. The big issue is the loss of control. Something the decentralized efforts need to take into account.


Q: A lot of DID discussion involves messaging.


Q: Loss of control thing, an entire branch of SAML figured out how to mitigate that, lives on in academic framework. Now has 10,000 IDPs. Governance is a big part of it.


Don forms the Open ID Foundation, resulted in chapter 6, a group of folks, WRAP came up as a next gen of how OAuth 1.0 could evolve. It was difficult for developers.


Vittorio: Also scenarios were restricted.


Justin: It also didn’t work well on mobile applications.


The cloud providers wanted things to be easy for developers, secure but not overkill. Enterprise folks wanted that for an enterprise audience.


Justin: Ch 6 was reaction to people’s experience with SAML, WS*, OAuth. We don’t want to do the exact same mistakes.


Then a big player threw down his bat and went home. Big blog entry. As much of a scandal as standards have.


Justin: The inventor says it’s bad. I’ve had to explain things so much.


[Put a link to the blog entry in the notes HERE]


Now you can separately authenticate the client.


Q: It reintroduced symmetric crypto as well.


OAuth 2 has 4 flows, 2 are back channel (no browser) 2 front. OAuth 2 enables a client to ask for a token to act on behalf of the user. A lot of things that were created in Open ID Connect are starting to become part of OAuth. ID token is claims and description of the authentication moment. A point where we gained tremendous stability.


Learnings here, cool thing about OAuth 2, SAML was an 800-page specification. Every single use case. Still things in SAML that solve problems we have today. But it was also heavy. It was a sophisticated party talking to a sophisticated partys. OAuth 2 for the world of mobile was important, sophisticated parties could talk to unsophisticated party.


We’re writing decentralized right now. Trying to figure out what in history should we be looking at?


Q: What were the security implementations we should be accounting for in DPKI? Looking at APTs and how they interact with things you’re building.


Signature wrapping is a big one, comes along with canonicalization. JSON LD, vulnerabilities because somebody did it wrong.


Justin: Someone turned off signature checking and everything works. It does not break the app. There have been and still are tons of SAML deployments turn this off.


Q: Turning off signature verification.


In Open ID 2.0, people didn’t trust assertions from people they didn’t know. So they trust only 5 identity providers and no one else.


Q: UX issues. Leads to phishing attacks. We figured out how to deal with crypto aspects of security but the UX aspects still remain.


Vittorio: Cartesian product of things you can do now.


Q: Everybody should pick any SSI demos that exist today, city, get credential riding the bus, look at it through your grandma’s eyes, figure out how many ways they can be phished.