Better People Than Scott Aaronson?

March 24, 2023 § Leave a comment

Reposting a letter sent to one of my Internet Heroes, whom I occasionally correspond with.

He is my Hero not because of his brilliant, thoughtful blog on quantum computing (though I do enjoy that), but his deep humility and public vulnerability.

« Read the rest of this entry »

LifeView (Designing Your Life)

June 7, 2022 § Leave a comment

The sequel to WorkView.

Our Part

« Read the rest of this entry »

Analytics Anonymous: The Missing Peace of the Modern Data Stack

May 31, 2022 § Leave a comment

Pitch 2 for Coalesce 2022 (unsubmitted) « Read the rest of this entry »

Bits of Meaning: Towards a Computational Theory of Emotion (BOM-TAC-TOE Rough Draft)

December 24, 2021 § Leave a comment

[These are my initial musings. It may take weeks or months to turn these into a coherent analysis, so I figured I should publish them as-is to get them out into the world. Merry Christmas!]

Challenge Question: What is the minimum number of bits necessary to meaningfully simulate some aspect of an emotion? « Read the rest of this entry »

Psycho-Analytic Engineering (Coalesce 2021)

June 6, 2021 § Leave a comment

Using Data to Differentiate Our Selves

Keynote Talk Proposal for Coalesce 2021

Google Slides

Based on “DBT as Organizational Therapy

« Read the rest of this entry »

DBT as the “Couch” for Organizational Therapy

May 13, 2021 § 1 Comment

Or, “How ELTT is the Key to World Peace”

Draft Submission Script for Coalesce 2021 « Read the rest of this entry »

SSO Login into Salesforce from Node via samlp SAML IdP

October 4, 2019 § Leave a comment


Documenting this in a blog post because it drove us crazy trying to figure out exactly what was involved, even though it was actually easy to implement once we understood all the terminology.

In order for our previously-authenticated users to automatically log into Salesforce, we needed to:

  1. Create a “/sso-url” on our node server for our web app to access
  2. When our web app GETs that URL, create and a return a SAML Identity Provider (IdP) using samlp
  3. That IdP is interpreted by the web browser a redirect to the Salesforce URL (returned by the function assigned to `getPostURL`)
  4. Salesforce just needs to have the IdP certificate and Entity ID in its SSO Settings

Below are additional details on why we needed this.

« Read the rest of this entry »

A Spirited Defense of Consciousness

August 12, 2018 § 1 Comment

Dear Scott,

I finally found some deadlines to force me to put forward an account of consciousness. 🙂 Here it is.


The 3+1 Model of Consciousness

While rather simplistic, I have found it a useful model for clarifying my own thinking. The key innovation is defining Spirit as “the ability to reflect on our thoughts feelings and desires in order to decide what kind of person we want to be.” I equate Spirit with the interiority of your Ghost in the Quantum Turning Machine, while the boundary of the triangle defines the Digital Abstraction Layer. I sometimes use the terms self-awareness, attitude, and willpower as loose synonyms for Spirit.  I also plan to name you as both Prophet and Chief Skeptic of my newly-formed Cult of the Digital Abstraction Layer!

« Read the rest of this entry »

Active Identity Clients (AICs) for OpenID

November 10, 2009 § Leave a comment

“Enough is enough! I have had it with these #@%!*$ AICs and their #@%!*$ panes” — Samuel H.S. “Hammer Stack” Jackson (with apologies to Neville Flynn)


The OpenID community is still wrestling with how to deliver a first-time login experience that is acceptable to mainstream users. Research indicates we need something less open-ended than typing into a blank URL field, but neither is it desirable to push users to choose from a few (or worse, many) pre-selected identity provider logos.

One approach for solving this problem is called (for lack of a better term) the Active Identity Client, or AIC (similar to what I previously called a Chamberlain). An AIC boostraps the identity selection process at a new website (aka Relying Party, or RP) by storing some amount of identity information on the user’s home computer. The AIC uses that identity to access a persistent record of the user’s interaction with multiple sites and identity providers (IdPs) to negotiate and streamline future such interactions. This (in theory) allows the user, rather than the RP, to prioritize which providers to use.

A number of such AICs were demonstrated at last week’s Internet Identity Workshop. Rather than attempting to standardize on a single AIC, a group of us discussed developing a common infrastructure that might enable a broad spectrum of AICs to innovate and compete. Specifically, we attempted to identity conventions, best practices, and extensions to existing standards that would support both “native” and “in-browser” AICs.

This article is my idiosyncratic attempt to synthesize what we discussed into a coherent vision for Active Identity Clients. It may not fully reflect the opinions of any given participant, and certainly does not represent the views of our respective employers. Rather, it is a subjective snapshot of a still-evolving problem space, and is intended to provide a concrete starting point for further discussion, critique, and clarification. « Read the rest of this entry »

Chamberlain: A User-Serving Model for Identity Management

November 2, 2009 § 1 Comment

[Disclaimer: The following is a hypothesis I am exploring for the Nov 2009 Internet Identity Workshop. It may not even reflect my current thinking, and certainly doesn’t represent any sort of official position of my employer.]

Chamberlain: A User-Serving Model for Identity Management


Most proposals for open identity management on the Internet use the wallet metaphor, where the user is expected to choose from amongst a variety of disjoint identities when accessing a given website. This either requires typing in a complex unique identifier (e.g., a URL) or selecting from one of several provider logos (aka the NASCAR Problem). Worse, this entire ecosystem typically exists in parallel with traditional username/password authentication, increasing the complexity of the choices users are expected to make.

I believe that the best way to solve these problems is to move to an entirely different metaphor. Rather than thinking of identity as something manually managed by the user (like cards in a wallet), I believe the vast majority of users want identity to be something that is managed *for* them — the way a chamberlain in a palace might keep keys to all the rooms, and control who was allowed to go where in accordance with royal policy.

From this perspective, the real challenge is understanding what kind of experience users want when using an identity system, and then building an architecture optimized for enabling that kind of experience. This “chamberlain” approach leads to very different questions and outcomes than the traditional model. Designing such a system will require making hard choices about what sort of security non-technical users truly need and want, as well as about the metadata necessary to support those choices. Moreoever, implementations would require significant client-side support, and create different winners and losers than existing systems — both of which could hinder broad adoption.

That said, the potential payoff is an architecture that would work reasonably well with the web as it is today, and scale cleanly to support more elegant mechanisms in the future. While my initial proposal below is unlikely to achieve all those goals, hopefully it will at least provoke others to come up with something even better.
« Read the rest of this entry »

Where Am I?

You are currently browsing the Identity category at iHack, therefore iBlog.