I’m back from participating in the NIST IDtrust workshop with Karen
Lewison. This was the 10th in a series, but the first I’ve attended.
I learned a lot. Presentations and panels can be found online at
Jeremy Grant made a presentation on the National Strategy for Trusted
Identities in Cyberspace (NSTIC). He said the President will make an
announcement on April 15, and there will soon be workshops to solicit
ideas from the private sector; we are looking forward to that. There
was interesting follow up during the workshop. A participant from a
financial institution told us in a private discussion that he doubted
his institution would be able to delegate authentication to an
external identity provider, due to security and liability concerns.
Paul Donfried gave a talk about Verizon’s Universal Identity Services.
Asked about the business model for providing identity services he said
that the identity provider could charge the relying party for a high
level of assurance. Elaine Newton, in one of her presentations,
talked about NSTIC, and about the Multi-Factor Authentication
In the long flight back to San Diego, Karen and I did some
brainstorming about all this and we came up
with three thoughts.
The first thought is that double redirection would help solve many of
the technical challenges of NSTIC. By double redirection I mean the
following: instead of the Relying Party (RP) relying on a certificate
signed by an Identity or Attribute Provider (IAP) and submitted by the browser,
the RP redirects the browser (via a 302 redirect or a form submission)
to the IAP, which authenticates the user and redirects the browser
back to the RP, passing a token or handle that the RP can use to
obtain identity and attribute information from the IAP. Thus the RP
relies on the IAP not only to provide credentials to the user, but
also to verify credentials presented by the user.
This provides a lot of flexibility. Any RP can gain the high level of
assurance provided by complex credentials (e.g. multi-factor
authentication including one-time passwords or revocable biometrics)
without having to implement verification procedures for those
credentials. The user can control what attributes the IAP will
disclose to the RP without having to juggle many attribute
certificates. The RP can use multiple IAPs, providing different
attributes, in the same transaction. And last but not least, Paul
Donfried’s business model becomes possible, since the IAP is aware of
There have been quite a few double redirection protocols: MS Passport
(now Windows Live ID), SAML Browser SSP Profile, Shibboleth, OpenID,
OAuth, etc. Some of them have serious security issues, but the PKAuth
protocol that we presented in our poster provides strong
security, without requiring the IAP and the RP to have prior knowledge
of each other. PKAuth is designed for social login, so it has the potential to unify the goals of NSTIC with the requirements of social networks.
The second thought is to use what we could call “vacuous certificates”.
By a vacuous certificate I mean a certificate that contains no
information about the subject of the certificate. It contains only a
public key and CA information, including revocation information. The
CA that issues the certificate is not an identity provider, it is
just, so-to-speak, a revocation provider. The user acquires a vacuous
certificate, and registers it with any number of identity providers,
which associate identity data or attributes with the certificate. In
other words, the identity data and attributes are metadata external to
the certificate, rather than data internal to the certificate.
This provides the obvious benefit that the user only needs to keep
track of one private key and certificate. Also, no certificates need
to be revoked and reissued when identity data or attributes change.
And this also seems to solve the liability problem: the user can
register the vacuous certificate with his or her bank, so that the
bank can be the identity provider for its own transactions. In a transfer of funds between two banks, both banks would be
identity providers for the same transaction.
The third thought goes back to double redirection. NSTIC emphasizes both security and privacy. For some
transactions, the IAP must authenticate the RP, for security reasons.
For other transactions, the IAP must not know the identity of the RP,
for privacy reasons. Direct presentation of credentials by the
browser to the RP ensures the latter; but it might be possible to
enjoy the benefits of double redirection while keeping the RP
anonymous. That would require an extension of the HTTP protocol to
support a form of double redirection where the browser hides the
identity of the initiator of the transaction (the RP).