Web Authentication Working Draft rev 7 (WD-07)

December 5th, 2017

Web Authentication Working Draft rev 7 (WD-07) is officially published here: https://www.w3.org/TR/2017/WD-webauthn-20171205/

NOTE: the latest official WebAuthn spec release is always available here: https://www.w3.org/TR/webauthn/ (so this presently yields WD-07)

Please also note that this spec is a _Working DRAFT_ and will change, possibly in “breaking” ways.

WebAuthn WD-07 features many changes from the prior version, here’s a selected list (for details, see the diffs linked-to below):

Diffs of WebAuthn WD-07 from WD-06:

WD-07 Release Page at github

Web Authentication Working Draft rev 6 (WD-06)

August 17th, 2017

Web Authentication Working Draft rev 6 (WD-06) is officially published here: https://www.w3.org/TR/2017/WD-webauthn-20170811/

NOTE: the latest official WebAuthn spec release is always available here: https://www.w3.org/TR/webauthn/ (so this presently yields WD-06)

Please also note that this spec is a Working DRAFT and will change, possibly in “breaking” ways.

WebAuthn WD-06 features several subtle-but-important changes from the prior version:
* The specification of the WebAuthn Relying Party Identifier (RP ID), and its processing, is corrected.
* Refined handling of authenticator transports in the #getAssertion algorithm
* Support for discovery of available platform authenticators
* Use of COSE algorithm identifiers and the COSE_Key format [RFC8152] for conveyance of the attested Credential Public Key (aka User Public Key).
* Attestation clarifications.
* Refined authenticator selection at credential creation time, and signaling of successful user verification at either credential creation time or assertion generation time.

HTML “inline” Diff: http://kingsmountain.com/doc/diff/diff-webauthn-index-master-tr-598ac41-WD-06–from–dda3e24-WD-05.html

PDF side-by-side text-only Diff: http://kingsmountain.com/doc/diff/diff-webauthn-index-master-tr-598ac41-WD-06–from–dda3e24-WD-05.pdf

WD-06 Release Page at github: https://github.com/w3c/webauthn/releases/tag/WD-06-20170811

Web Authentication Working Draft rev 5 (WD-05)

May 7th, 2017

Web Authentication Working Draft rev 5 (WD-05) is officially published here: https://www.w3.org/TR/2017/WD-webauthn-20170505/

The latest official WebAuthn spec release is always available here: https://www.w3.org/TR/webauthn/

Please note that this spec is only a Working DRAFT and will change, possibly in “breaking” ways. While not a candidate recommendation, this version is informally intended by the working group to be an Implementer’s Draft, which will be used for experimenting with implementations of the API.

WebAuthn WD-05 features many significant changes from the prior version:
* Alignment with Credential Management (CredMan): https://w3c.github.io/webappsec-credential-management/
* Using the term Public Key Credentials rather than Scoped Credentials
* Algorithms updated to more precisely define their operations and to be CredMan compatible
* Expanded and more explicit specification of the extensions framework
* Terminology expansion and polishing
* and more…

HTML “inline” Diff: http://www.kingsmountain.com/doc/diff/diff-webauthn-index-master-tr-dda3e24-WD-05–from–index-master-tr-ce7925c-WD-04.html

PDF side-by-side text-only Diff: http://kingsmountain.com/doc/diff/diff-webauthn-index-master-tr-dda3e24-WD-05–from–index-master-tr-ce7925c-WD-04.pdf

Wd-05 Release Page at github: https://github.com/w3c/webauthn/releases/tag/WD-05-20170505

HTTP cookie processing algorithm in terms of Same Origin Policy and “effective Top Level Domains (eTLDs)

April 30th, 2015

This is a community-service posting: The purpose is to unambiguously state the specification of “cookie processing wrt public suffixes”.

Why go thru the effort of doing this: It is somewhat difficult to tease this out of the requisite specification(s) and associated documents, e.g., [RFC6265] and the effective Top Level Domain List, and so here it is (corrections/comments welcome)..

HTTP cookie processing algorithm in terms of Same Origin Policy and “effective Top Level Domains (eTLDs)” aka “Public Suffixes”

=JeffH sez: it’s long — read it anyway :)

RFC6797 “HTTP Strict Transport Security (HSTS)” is published

November 21st, 2012

RFC6797 “HTTP Strict Transport Security (HSTS)” is now available.

It’s been a long haul to get to this point, and I thank all the folks who have contributed along the way, i.e. Collin Jackson and Adam Barth who had the original idea [ForceHTTPS] and co-authored the spec, and all the other folks who contributed to its gestation (from the Acknowledgements appendix):

The authors thank Devdatta Akhawe, Michael Barrett, Ben Campbell,
Tobias Gondrom, Paul Hoffman, Murray Kucherawy, Barry Leiba, James
Manger, Alexey Melnikov, Haevard Molland, Yoav Nir, Yngve N.
Pettersen, Laksh Raghavan, Marsh Ray, Julian Reschke, Eric Rescorla,
Tom Ritter, Peter Saint-Andre, Brian Smith, Robert Sparks, Maciej
Stachowiak, Sid Stamm, Andy Steingrubl, Brandon Sterne, Martin
Thomson, Daniel Veditz, and Jan Wrobel, as well as all the websec
working group participants and others for their various reviews and
helpful contributions.

Thanks to Julian Reschke for his elegant rewriting of the effective
request URI text, which he did when incorporating the ERU notion into
the updates to HTTP/1.1 [HTTP1_1-UPD]. Subsequently, the ERU text in
this spec was lifted from Julian’s work in the updated HTTP/1.1
(part 1) specification and adapted to the [RFC2616] ABNF.

See also the Wikipedia HSTS article for various other information about HSTS and deploying it.

=JeffH sez check it out :)

HTTP Strict Transport Security (HSTS) Approved as Proposed Standard RFC

October 2nd, 2012

As I’d noted back in July, the draft HSTS spec was in IETF-wide last call, from which we exited in August with various helpful comments. We applied summore elbow grease to the ol’spec and shipped it to the IESG (Internet Engineering Steering Group) for further inspection, received more good comments, subsequently applied more tweaks and polish, and voila(!), this morning we have this little missive in our email…

[websec] Protocol Action: ‘HTTP Strict Transport Security (HSTS)’ to Proposed Standard (draft-ietf-websec-strict-transport-sec-14.txt)

At this point, the draft HSTS spec will be placed on the RFC Editor’s queue (which is fairly large & diverse) and will emerge in several weeks as an RFC with a proper RFC number and all.

Many thanks to all who’ve contributed, especially to Collin Jackson & Adam Barth for originally inventing this approach (which they dubbed “ForceHTTPS“).


PS: The Wikipedia HSTS entry has a consolidated specification history as well as information regarding implementation and deployment.

The Death of the Internet?

July 24th, 2012

The deliberately provocative title of this post is also the deliberately provocative title of a new book, conceived and edited by colleague Markus Jakobsson, that’s now available:

The Death of the Internet

The book analyzes the overall problem of criminal activity on the Internet—namely fraud—and its ensuing damage. It then goes on to examine how criminals profit, how the Internet’s systems work and fail, and issues in the mobile and physical worlds. It concludes by outlining various solution proposals, examining the crucial role of user experience, and poses a set of guiding questions to ask ourselves as we go forward. The essential premise is that we collectively need to keep fraud under control or we risk losing the open freely generative Internet as we know it.

The book sections are authored by a broad cross-section of Web and Internet security researchers and engineers from across academia and industry. They collectively present a detailed multifaceted picture of the spectrum of issues and solutions.

I and Andy Steingruebl co-authored a chapter entitled “Web Security Remediation Efforts” describing aspects of overall web security issues and on-going efforts in, for example, the W3C and IETF to address them.

=JeffH sez check it out :)

RLBob: SUNet ID and the Registry and Directory Infrastructure

July 14th, 2012

Primary among RL “Bob” Morgan‘s (aka “RLBob”) many contributions during his time at Stanford Networking Systems, was being a key visionary and instigator behind the Stanford University SUNet ID project, as well as the underlying Registry and Directory Infrastructure.

The main use cases RLBob latched onto in the early 1990s were having a centralized institution-wide authentication infrastructure, and a “flat” email address namespace. Both use cases drive requirements for having a centrally-maintained yet delegated-management notions of person naming.

At that time, all email addresses at Stanford were relative to some particular system or host. So, you had to remember whether some Stanford correspondent’s email address was @forsythe.stanford.edu, or @leland.stanford.edu, or @networking.stanford.edu, or @whatever.stanford.edu. Additionally, one’s online name, or names, were invariably driven by either/both of the unix-based academic computing environment (up to 8 alphanumeric characters) or/and the administrative mainframe-based environment (a often impenetrable six-alpha-character-with-dot concoction, such as “bl.foo”). Good luck with having online apps decently leverage your actual meatspace natural name(s) in this sort of environment.

Now, this of course was a burden for users. What if you changed departments? What if you were affiliated with more than one department? Well, you had more than one email address and it was pretty much up to you to figure out how to deal with that (this is of course just one aspect of the raft of issues we had at the time with the existing, essentially ad-hoc system).

RLBob was always very conscious of usability for the common non-computer-literate folk. He believed strongly in the value to the individual of having one’s online persona map reasonably to one’s offline meatspace persona. To him this meant figuring out technologies, policies, and procedures such that one’s natural name(s) could be represented and leveraged online as (ahem) naturally as possible. Also, that changes to one’s natural names (as necessitated by real world events/needs) could be accommodated reasonably.

So, to try to shorten a quite long, nuanced, multi-faceted story, here’s the early 1996 versions of the requirements and design documents RLBob crafted. We used these docs to inform the overall multi-phase SUNet ID et al project (which was well along by that time)..



The modern present-day, user-facing SUNet ID description is here..


In the first phase of the project (as I recall), we crafted SUNet IDs (featuring various name forms, e.g., short and long) and enabled sunetid@stanford.edu email delivery. However, this did not account for all the various institutional repositories of identity data, and did not provide for mapping between them.

So in the second phase of the project, RLBob championed the notion of a Registry, having this definition..

“A registry is a service that serves the needs of applications for coordinated maintenance of identity information about a class of business objects.”

..E.g., some classes are: People, services, groups. A registry is a transaction-oriented service. Client applications use one mostly to enter and update information, I.e. a registry is write- and update-oriented. Read-oriented access is typically handled by other components of the overall system, e.g. the Directory.

And thus the “Registry and Directory Infrastructure” notion took shape.

Below is a case-history presentation about this system that I crafted for a conference in early 1999. RLBob, in his Enterprise Architect role, made significant contributions to the overall thinking behind the entire system, as well as key detailed design aspects. Note also that this was a large project with many contributors crafting various aspects, including architecture, of the overall multi-faceted system (see especially the Acknowledgements on slides 23 & 24)..

Stanford Registry & Directory Infrastructure

I am honored to have participated in this project and and been part of such a talented team.

See also the RLBob tribute page, as well as my other recent post about him and his recent passing..

RLBob Migrates to The Cloud

Angela Lee Memorial Hike

July 14th, 2012

There will be a memorial hike in honor of Angela Lee, the late wife of my (and RLBob‘s) colleague Rob Riepel (of Stanford Networking Systems), on Sat 11-Aug-2012, outside of Lone Pine, CA.

Angela was another (relatively) recent victim of cancer, left us at far too young of age, and is sorely missed. See Pages 3 & 4 of of the Institute for Stem Cell Biology and Regenerative Medicine‘s (where she worked) September 2011 newsletter for an in-depth obituary.

See this page for details of the hike and pics of its beautiful high-country environs.

Given the nature of her work, perhaps Angela and RLBob (given the modus operandi of his recent unfortunate cloud migration) will meet Cloud-side — they apparently, and entirely coincidentally, have a fair bit in common.

updated 2016-10-25: fix link to Stem Cell Newsletter — thanks Rob!

RLBob migrates to The Cloud

July 13th, 2012

A day or two earlier this week, RL “Bob” Morgan, a long time colleague and friend of many of us in the Higher-Ed, Identity, directory, University of Washington, Stanford, IETF, OASIS, Internet2 Middleware communities passed away due to complications from his long bout with cancer and treatments thereof.

Bob made positive contributions wherever he traveled and to whatever he participated in (notably his beloved family). I personally benefited greatly from his friendship and mentoring, and am going to miss him so very terribly.

Various of his colleagues/friends had been joking online with him about whether “this time”, his second stem cell transplant, was “an OS re-install” or whatever, and so he definitively cleared it up for all of us in his imitable fashion, with this blog post entitled “Metaphorically on “day zero” (21-Jun-2012)..

Just to clear this up, for all you computer people.
Last time was “re-install OS and restore from backup”.
This time is “install a different OS”.
Next time is “migrate to the cloud”.
Got it?

Unfortunately, “this time” and “next time” got conflated, and RLBob indeed has migrated to The Cloud. :-(

Hey big guy, are you gonna help them deploy SCIM up there?

Tributes to RL “Bob” can be found (and posted) here: