Musings on Digital Identity

Category: Safety

SecEvent Delivery specs are now RFCs 8935 and 8936

IETF logoThe SecEvent Delivery specifications, “Push-Based Security Event Token (SET) Delivery Using HTTP” and “Poll-Based Security Event Token (SET) Delivery Using HTTP”, are now RFC 8935 and RFC 8936. Both deliver Security Event Tokens (SETs), which are defined by RFC 8417. The abstracts of the specifications are:

Push-Based Security Event Token (SET) Delivery Using HTTP:

This specification defines how a Security Event Token (SET) can be delivered to an intended recipient using HTTP POST over TLS. The SET is transmitted in the body of an HTTP POST request to an endpoint operated by the recipient, and the recipient indicates successful or failed transmission via the HTTP response.

Poll-Based Security Event Token (SET) Delivery Using HTTP:

This specification defines how a series of Security Event Tokens (SETs) can be delivered to an intended recipient using HTTP POST over TLS initiated as a poll by the recipient. The specification also defines how delivery can be assured, subject to the SET Recipient’s need for assurance.

These were designed with use cases such as Risk & Incident Sharing and Collaboration (RISC) and Continuous Access Evaluation Protocol (CAEP) in mind, both of which are happening in the OpenID Shared Signals and Events Working Group.

SecEvent Delivery specs sent to the RFC Editor

IETF logoI’m pleased to report that the SecEvent delivery specifications are now stable, having been approved by the IESG, and will shortly become RFCs. Specifically, they have now progressed to the RFC Editor queue, meaning that the only remaining step before finalization is editorial due diligence. Thus, implementations can now utilize the draft specifications with confidence that that breaking changes will not occur as they are finalized.

The specifications are available at:

HTML-formatted versions are also available at:

SecEvent Delivery specs now unambiguously require TLS

IETF logoThe SecEvent delivery specifications have been revised to unambiguously require the use of TLS, while preserving descriptions of precautions needed for non-TLS use in non-normative appendices. Thanks to the Security Events and Shared Signals and Events working group members who weighed in on this decision. I believe these drafts are now ready to be scheduled for an IESG telechat.

The updated specifications are available at:

HTML-formatted versions are also available at:

SecEvent Delivery Specs Addressing Directorate Reviews

IETF logoI’ve published updated SecEvent delivery specs addressing the directorate reviews received during IETF last call. Thanks to Joe Clarke, Vijay Gurbani, Mark Nottingham, Robert Sparks, and Valery Smyslov for your useful reviews.

The specifications are available at:

HTML-formatted versions are also available at:

Security Event Token (SET) delivery specifications in IETF Last Call

IETF logoThe two Security Event Token (SET) delivery specifications have been updated to address additional Area Director review comments by Benjamin Kaduk. See the History entries for descriptions of the changes, none of which were breaking. Both documents are now open for IETF Last Call reviews.

Thanks again to Ben for his thorough reviews. And thanks to Annabelle Backman for doing the editing for this round.

The specifications are available at:

HTML-formatted versions are also available at:

JWTs helping combat fraudulent and unwanted telephone calls

IETF logoI wanted to bring two excellent articles by the IETF on work by the STIR working group to combat fraudulent and unwanted telephone calls to your attention:

Abstract: Providers of voice over IP in the United States will be required to implement the IETF’s Secure Telephony Identity Revisited (STIR) protocol as a result of recently enacted legislation to address some of the root causes of illegal robocalling on the telephone network.

Abstract: Recently, the output of the IETF Secure Telephony Identity Revisited (STIR) working group has received considerable attention from service providers, regulators, and the press because it addresses some of the root causes of the illegal robocalling which has crippled the telephone network.

I love this work for two reasons. First, like the rest of you, I receive a huge volume of unwanted and often fraudulent phone calls. I love that engineers and regulators are partnering to take concrete steps to reduce the volume of these illegal and annoying calls.

Second, I love it that the STIR protocols are using JSON Web Tokens (JWTs) under the covers as the format to represent verifiable statements about legitimate uses of telephone numbers, enabling verifiable Caller ID. It’s often said that one sign of a standard having succeeded is that it’s used for things that the inventors never imagined. This is certainly such a case! I’m proud that the JSON Web Token, which we originally designed with digital identity use cases in mind, is now being used in a completely different context to solve a real problem experienced by people every day.

Security Event Token (SET) delivery specifications addressing Area Director reviews

IETF logoThe two Security Event Token (SET) delivery specifications have been updated to address the Area Director review comments by Benjamin Kaduk. The changes to address Ben’s comments were made in the previous versions (-08 for Push and -07 for Pull.) The latest versions addressed editorial nits.

Thanks to Ben for his thorough reviews! And thanks to Annabelle Backman for reviewing the changes.

The specifications are available at:

HTML-formatted versions are also available at:

Security Event Token (SET) delivery specifications updated in preparation for IETF 105

IETF logoThe two Security Event Token (SET) delivery specifications have been updated to address working group feedback received, in preparation for discussions at IETF 105 in Montreal. Only minor terminological updates were made to the Push Delivery spec following the working group last call (WGLC) changes in the previous recent revisions. Thanks to Annabelle Backman for the edits to the Push Delivery spec.

The changes to the Poll Delivery spec further aligned it with the Push spec, referencing shared functionality, rather than duplicating it. I believe that the Poll spec is now ready for working group last call.

The specifications are available at:

HTML-formatted versions are also available at:

Security Event Token (SET) delivery specifications updated in preparation for IETF 104

IETF logoThe two Security Event Token (SET) delivery specifications have been updated to address working group feedback received, in preparation for discussions at IETF 104 in Prague. The Push Delivery spec went through working group last call (WGLC). It has been updated to incorporate the WGLC comments. Changes made are summarized in the spec change log, the contents of which were also posted to the working group mailing list. Thanks to Annabelle Backman for the edits to the Push Delivery spec.

It’s worth noting that the Push Delivery spec and the Security Event Token (SET) are now being used in early Risk and Incident Sharing and Coordination (RISC) deployments, including between Google and Adobe. See the article about these deployments by Mat Honan of BuzzFeed.

Changes to the Poll Delivery spec are also summarized in that spec’s change log, which contains:

  • Removed vestigial language remaining from when the push and poll delivery methods were defined in a common specification.
  • Replaced remaining uses of the terms Event Transmitter and Event Recipient with the correct terms SET Transmitter and SET Recipient.
  • Removed uses of the unnecessary term “Event Stream”.
  • Removed dependencies between the semantics of maxEvents and returnImmediately.
  • Said that PII in SETs is to be encrypted with TLS, JWE, or both.
  • Corrected grammar and spelling errors.

The specifications are available at:

HTML-formatted versions are also available at:

An update on our war against account hijackers

I recommend reading Google’s post An update on our war against account hijackers. It describes the kinds of measures taken by professionally-run Identity Providers to defend against account takeover.

A message not stated but implied is that consumers and Web sites are far better off depending upon identities provided by organizations with the resources and dedication to successfully fight takeover attempts. Sites with their own username/password login systems without these defenses are vulnerable, and would be better off using federated identities from professionally-run Identity Providers.

Internet Safety Technical Task Force Report

Enhancing Child Safety and Online TechnologiesThe Internet Safety Technical Task Force has released its report on online child safety: Enhancing Child Safety and Online Technologies: Final Report of the Internet Safety Technical Task Force to the Multi-State Working Group on Social Networking of State Attorneys General of the United States. During its year-long effort, the task force surveyed existing research and evaluated technologies that are relevant to child safety online.

One thing noticeably absent from the report, given the number of different technologies presented to and discussed by the task force, is references to any of them. In the end, the task force took the position that while technologies can help, that none is a silver bullet, and none are a substitute for parents and other adults who are active in children’s lives. I have to agree with them.

The Technical Advisory Board appointed by the task force evaluated possible technological approaches to making children safer online. A number of its members were individuals active in the identity and security communities, including Ben Adida of Harvard, Todd Inskeep of Bank of America, RL “Bob” Morgan of the University of Washington, and Danny Weitzner of MIT. The Technology Advisory Board Report summary included:

In sum, the TAB review of the submitted technologies leaves us in a state of cautious optimism, with many submissions showing promise. The children’s online safety industry is evolving, and many of the technologies we reviewed were point solutions rather than broad attempts to address the children’s safety online as a whole. There is, however, a great deal of innovation in this arena as well as passionate commitment to finding workable, reasonable solutions from companies both large and small. Thus, the TAB emerged from its review process encouraged by the creativity and productivity apparent in this field.

By the end of the review process, the TAB ultimately determined that no single technology reviewed could solve every aspect of online safety for minors, or even one aspect of it one hundred percent of the time. But clearly there is a role for technology in addressing this issue both now and in the future, and most likely, various technologies could be leveraged together to address the challenges in this arena.

Some critics may object to the use of technology as a solution, given the risk of failure and lack of total certainty around performance. However, the TAB believes that although it is indeed true that even the cleverest, most robust technology can be circumvented, this does not necessarily mean that technology should not be deployed at all. It simply means that – even with deployment of the best tools and technologies available to jumpstart the process of enhancing safety for minors online – there is no substitute for a parent, caregiver, or other responsible adult actively guiding and supporting a child in safe Internet usage. Likewise, education is an essential part of the puzzle. Even the best technology or technologies should be only part of a broader solution to keeping minors safer online.

Makes sense to me…

From a personal perspective, I’d like to thank the task force for giving me the opportunity to describe how Information Cards can be used to convey verified claims about individuals, and to thank IDology and Novell for making this real with a working demo of verified age cards for the task force.

I also enjoyed working with Jules Cohen and Chuck Cosson of Microsoft’s Trustworthy Computing and Law and Corporate Affairs groups on the identity technology aspects of Microsoft’s inputs to the task force. I have enormous respect for the balanced and thoughtful perspectives they brought to the discussion, as exemplified by their paper Digital Playgrounds: Creating Safer Online Environments for Children, which was submitted to the task force. Their proposal that existing offline identity proofing ceremonies could be leveraged to enhance safety online resonated with many of the task force members.

I expect media and blog coverage of the report to be active over the next few days. An early sampling includes:

These are important and interesting issues. It’s a discussion well worth following and participating in.

PAPE Specification Approved and Ready for Use

OpenID logoAs I just announced on openid.net, OpenID Provider Authentication Policy Extension 1.0 (PAPE) has just been just been approved as an OpenID specification. Deployment of PAPE will go a long way towards mitigating the phishing vulnerabilities of password-based OpenIDs by enabling OpenID Relying Parties to request that OpenID Providers employ phishing-resistant authentication methods when authenticating users and for OpenID Providers to inform Relying Parties whether this (and other) authentication policies were satisfied.

It’s tempting to say that the approval of the specification is the fulfillment of the promise of the OpenID/CardSpace collaboration for phishing-resistant authentication introduced by Bill Gates and Craig Mundie the RSA Security Conference last year, but it’s really just an enabling step. The true value of PAPE will come when it is widely deployed by security-conscious OpenID Relying Parties, and the use of phishing-resistant authentication methods, such as Information Cards and others, is widespread and commonplace. Let the deployments begin!

Systems Will Be Breached

Scott Merrill writes that:

At the 25th Chaos Communication Congress (CCC) today, researchers will reveal how they utilized a collision attack against the MD5 algorithm to create a rogue certificate authority.

As Scott says, this is pretty big news, so I encourage you to read his post and the paper describing the breach. He also writes that “affected CAs are switching to SHA-1”.

This episode immediately reminded me of a principle that Kim often espouses:

The way to design securely is to assume your system WILL be breached and create a design that mitigates potential damage.

I’ll leave it to others to debate whether CAs switching to SHA-1 is likely to be an effective mitigation in the long term and to discuss how long it will take before this particular breach has been worked around. But this sure provides (more) convincing evidence that designing systems with the assumption that they will be breached is essential to those systems’ robustness and long-term viability.

Online Identity Theft and Digital Playgrounds Whitepapers

I wanted to bring your attention to two whitepapers covering important Internet identity topics that were published by members of Microsoft’s Trustworthy Computing and Privacy teams, both announced on the blog The Data Privacy Imperative.

The first is “Online Identity Theft: Changing the Game — Protecting Personal Information on the Internet” by Jules Cohen, Brendon Lynch, and other members of Microsoft’s Trustworthy Computing team. Per the announcement, the paper:

… for the first time describes in detail Microsoft’s comprehensive strategy for curbing online identity theft. In addition to describing current Microsoft initiatives, the paper outlines long-term solutions for “changing the game” by ending reliance on “shared secrets” for authentication.

Relying on “shared secrets,” such as usernames, passwords, birthdates and government ID numbers to establish the right to do something online, creates security problems because they are relatively easy to steal and can be difficult to remember, update and manage. We need to employ new identity practices online that are just as reliable but better protect against fraud and abuse, and that’s where Information Cards come in …

The paper has been greeted by favorable reviews, including an Information Week article that also describes the role that the Information Card Foundation can play and a NetworkWorld article by Dave Kearns that concludes “Download this important paper, read it, then act on it.”

The second is “Digital Playgrounds: Creating Safer Online Environments for Children” by Jules Cohen of Microsoft’s Trustworthy Computing team and Chuck Cosson, Policy Counsel on privacy and safety issues, with some input from me. The paper was presented to the Internet Safety Technical Task Force (ISTTF) by Jules and submitted by Microsoft as input to the task force. As Jules wrote about the approach:

The Digital Playgrounds paper outlines a framework that would enable the creation of optional online “walled gardens,” specifically for children and trusted adults. These online sites would only be accessible by folks with trusted and age verified ‘digital identities.’ This framework suggests achieving this by allowing trusted offline parties, who have the ability to meet with a parent and child in real life, examine the appropriate documents and then issue extremely secure digital identities based on these in in-person proofing moments. The framework we have outlined is largely a technical solution to the age verification challenge, but we believe that the nontechnical aspects of the problem will be as difficult to solve as the technical ones, if not more so. For example, government and industry will need to work together on designing the necessary criteria for in-person proofing events as well as the subsequent issuing, auditing and revoking of these digital identity cards.

I especially encourage people to consider the possibility that existing offline identity proofing ceremonies might be leveraged to enhance safety online as well.

Powered by WordPress & Theme by Anders Norén