So yesterday evening, not long after sundown, we drove out to our usual spot in the countryside west of Santa Barbara to watch a big launch of a big rocket — NROL-71 — from Vandenberg Air Force Base. The launch had been scrubbed three times already, the last one only seven seconds from ignition. Just before we arrived, there was a bright light in the western sky, exactly above the launch site. A trail was visible, and I thought maybe they had already launched the rocket… or a rocket, perhaps to test winds at high altitudes or something.
In search, Google has a 90%+ share worldwide. But I’m not sure that makes it a monopoly, as long as it has real competition. With Bing is does.
For example, recently I wanted to find a post Andrew Orlowski wrote for The Register in the early 00s. I remembered that it was about The Cluetrain Manifesto (which he called “Candide without the irony”—a great one-liner I can’t forget), and also mentioned John C. Dvorak, another Cluetrain non-fan. So I did this search on Google:
Summary: Verifiable credential exchange is the foundation of decentralized, online identity. This post describes how it works.
I realized last week that I'd never explained verifiable credential exchange as a stand-alone topic—it was always buried in something else.
Multi-source identity (MSI) depends on issuing, exchanging, and verifying digital credentials. The specification for verifiable credentials is being formulated by the World Wide Web Consortium’s Verifiable Credentials Working Group. Verifiable credentials provide a standard way to express credentials in a way that is cryptographically secure, privacy respecting, and automatically verifiable.
Credentials are defined by their issuer in a credential definition. The credential definition links the public decentralized identifier (DID) of the issuer, the schema for the credential, and a revocation registry for the credential. The definition, public DID, schema, and revocation registry are all stored on a distributed ledger that is used for decentralized discovery. (See What Goes on the Ledger (PDF)
The OpenID Connect Federation 1.0 specification is being developed to enable large-scale federations to be deployed using OpenID Connect. It enables trust among federation participants to be established through signed statements made by federation operators about federation participants.
The design of this specification builds upon the experiences gained in operating large-scale SAML 2.0 federations, and indeed, is authored by people having practical experience with these federations. The primary authors are Roland Hedberg and Andreas Åkre Solberg, with additional contributions by Samuel Gulliksson, John Bradley, and myself, as well as members of the OpenID Connect working group, which is the home of the specification.
A key innovation that differentiates OpenID Connect federations from most SAML 2.0 federations is that OpenID Connect federation employs heirarchal metadata, where participants directly publish statements about themselves, versus the aggregated metadata approach used by many SAML 2.0 federations, where Continue reading "OpenID Connect Federation Specification"
Much has been written about Iridium’s history, and Ed’s role in driving its satellites into space, most of it negative toward Ed. But I’ve always thought that was at least partly unfair. Watching the flow of news about Iridium at the time it was moving from ground to sky, it was clear to me that Iridium would have remained on the ground if Ed wasn’t a tough bastard about making it fly.
I had a bunch of errands to run today, but also a lot of calls. When I got up from my desk around 4pm with plans to head out in the car, I found five inches of snow already on the apartment deck. Another five would come after that.
So I decided to walk down to the nearest dollar store, a few blocks north on Broadway, which is also downhill in this part of town, and at least pick up some deck lights to replace the ones that burned out after glowing there for several years.
What I found on Broadway was total gridlock, because too many cars and trucks couldn’t move. Tires all over spun in place, saying “zzzZZZZzzzZZZ.” After I picked up a couple 5-foot lengths of holiday lights for $1 each at the dollar store, I walked back up past the same stuck length of cars Continue reading "New York lights"
Key ID confirmation method considerations suggested by Jim Schaad have been added to the Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) specification. Per discussions in the working group meeting in Bangkok, it’s now time for the shepherd review.
The JSON Web Token (JWT) Best Current Practices (BCP) specification has been updated to address the review comments from Security Area Director (AD) Eric Rescorla. Thanks to Eric for the review and to Yaron Sheffer for working on the responses with me.
Note that IETF publication has already been requested. The next step is for the shepherd review to be submitted and responded to.
The Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) specification has been updated to addresses a few additional Working Group Last Call (WGLC) comments. All of the (few) changes were about improving the clarity of the exposition. I believe that this completes addressing the WGLC comments.
Thanks to Roman Danyliw for helping to categorize the remaining comments that needed to be addressed.
Digital media company Refinery29, facing a 5% revenue shortfall for the year, is cutting 10% of its workforce, or about 40 employees.Digital media company Refinery29, facing a 5% revenue shortfall for the year, is cutting 10% of its workforce, or about 40 employees.
Company co-founders and co-CEOs Philippe von Borries and Justin Stefano announced the cuts in an internal memo. “While our 2018 revenue will show continued year-over-year growth, we are projecting to come in approximately 5% short of our goal,” they wrote. As a result of its financial pressures, “we will be parting ways with approximately 10% of our workforce.”
The latest cuts, first reported by the Wall Street Journal, come after New York-based Refinery29 laid off 34 employees in December 2017.
Now that the Security Event Token (SET) specification is RFC 8417, the SecEvent working group is working on defining the SET delivery mechanisms. This week, both the push-based and poll-based SET delivery specs have been updated to simplify their exposition and reduce duplication of text between the drafts. Thanks to Annabelle Backman for doing the bulk of the recent work on the push-based delivery spec. The latest versions of both specs contain these updates:
Addressed problems identified in my 18-Jul-18 review message titled “Issues for both the Push and Poll Specs”.
Changes to align terminology with RFC 8417, for instance, by using the already defined term SET Recipient rather than SET Receiver.
Applied editorial and minor normative corrections.
Updated Marius Scurtescu’s contact information.
In addition, the latest version of the poll delivery spec also contains this update:
Summary: Sovrin is more than a ledger and its claim to being a decentralized identity system rests on more than that. Sovrin comprises three layers, each of which promotes and strengthens decentralization and self-sovereign identity. This post discusses each layer and the decentralized features that underpin it.
Decentralized architectures require that care is taken in each component or layer to ensure that the resulting system will not contain hidden weaknesses. That doesn't just apply to the system itself, but also to the ways it is governed. And all decentralized systems are governed. The governing might be ad hoc or hidden, but it's there.
I've written a lot about distributed ledgers, Sovrin, governance, and decentralization over the past several years. Here's a partial list:
In advance of this gathering, Linux Journal, which I serve as editor-in-chief (but which I can’t use as a blog, meaning editing it live is maybe do-able but not easy), published When the problem is the story. I wanted it up, on the outside chance that stories themselves, as journalism’s stock-in-trade, might get discussed. Because stories are a Hard Problem: maybe one we can’t solve.
The panels are interesting but so far tell me nothing I didn’t already know, though some of it is interesting at the jargon level.
As Alex Simons recently wrote, it’s time for token binding. Especially now that the core specs are done, now’s the time for platforms and applications to deploy Token Binding. This will enable replacing bearer tokens, which can be stolen and reused, with Token Bound tokens, which are useless if stolen. This is a huge security benefit applicable to any tokens used over TLS, including browser cookies, OAuth access tokens and refresh tokens, and OpenID Connect ID Tokens.