A quick reminder that the vote to approve updates to the OpenID IPR Policy document is under way. If you’re an OpenID Foundation member, I encourage you to vote to approve the updates now at https://openid.net/foundation/members/polls/151.
As described in the OpenID Foundation post Proposed Revisions to OpenID IPR Policy Document, the updates enable the use of electronic signatures on contributor agreements instead of requiring on-paper signatures and simplify the descriptions of working group contributors, all without changing the IPR rights of any party.
The foundation needs 30% of the membership to vote in order for the changes to take effect, so please take a moment and vote now. Thanks!
Summary: Self-sovereign identity is multi-source, but not all multi-source identity systems are self-sovereign. Self-sovereignty requires that people and organizations have control of their credentials and interact as peers.
The world is full of credentials. Some, like a driving license, an employee ID card, a passport, or a university diploma are widely recognized as such. But many other things are also credentials: a store receipt, a boarding pass, or a credit score, for example. Credentials, designed properly, allow verifiable data to be employed in workflows without centralized hubs, point-to-point integrations, or real-time communication between the various players. Credentials enable decentralized, asynchronous workflows.
Summary: The real world is messy and unpredictable. Creating an identity system that is flexible enough to support the various ad hoc scenarios that the world presents us with can only be done using a decentralized system like Sovrin that allows multiple credentials from various authorities to be shared in the ways the scenario demands.
Recently Joe Andrieu gave a presentation about the role of multiple assertions in a real-life situation—an automobile accident. As I listened, I thought it was an excellent example because it showed clearly the power of being able to bring multiple, independent credentials to
How would you feel if you had been told in the early days of the Web that in the year 2018 you would still need logins and passwords for damned near everything.
Your faith in the tech world would be deeply shaken, no?
And what if you had been told that in 2018 logins and passwords would now be required for all kinds of other shit, from applications on mobile devices to subscription services on TV?
Or worse, that in 2018 you would be rob-logged-out of sites and services frequently, whether you were just there or not, for security purposes — and that logging back in would often require “two factor” authentication, meaning you have to do even more work to log in to something, and that (also for security purposes) every password you use would not only have be different, but impossible for any human to remember, especially when average Continue reading "Please let’s finally kill logins and passwords"
Hyperledger Indy's README.md explains how to start the @Sovrin test pool on localhost using docker and in a docker network.
Doing it this way the pool is not reachable from clients that are not on your local machine. Building a mobile app then has the problem that the phone can't talk to the test pool because neither localhost nor the private docker network are reachable.
Starting the test pool on a specific IP address
Dockerfile ci/indy-pool.dockerfile supports an optional pool_ip param that allows changing the IP address of the pool nodes in the generated pool configuration.
You can start the pool with e.g. the IP address of your development machine's WIFI interface so that mobile apps in the same network can reach the pool.
# replace 192.168.179.90 with your wifi IP address docker build --build-arg pool_ip=192.168.179.90 -f ci/indy-pool.dockerfile -t
A few weeks ago, while our car honked its way through dense traffic in Delhi, I imagined an Onion headline: American Visitor Seeks To Explain What He’ll Never Understand About India.
By the norms of traffic laws in countries where people’s tendency is largely to obey them, vehicular and pedestrian traffic in the dense parts of Indian cities appears to be chaotic to an extreme. Yet it’s clearly at least … well, organic. People do seem to go where they want, individually and collectively. Somehow. Some way. Or ways. Many of them. Alone and together. Never mind that a four-lane divided highway will have traffic moving constantly, occasionally in both directions on both sides—and that it includes humans, dogs, cattle, rickshaws and bikes, some laden with bags of cargo that look like they belong in a truck, in addition to cars, trucks and motorcycles, all packed together and honking constantly.
This draft contains a few refinements since the first candidate recommendation but no substantial changes. The new CR was needed to fulfill the W3C’s IPR protection requirements. The few changes were based, in part, upon things learned during multiple interop events for WebAuthn implementations. The working group plans to base coming the Proposed Recommendation on this draft.
Any data protection regulator faces certain unique challenges. The ubiquitous collection and use of personal data by service providers in the modern economy creates a vast space for a regulator to oversee. Contraventions of a data protection regime may not immediately manifest and when they do, may not have a clear monetary or quantifiable harm. The enforcement perimeter is market-wide, so a future data protection authority will necessarily interface with other sectoral institutions. In light of these challenges, we present a model for enforcement of a data protection regime based on risk-based supervision and the use
Summary: This article describes the role that the Sovrin Foundation and associated groups play in governing, operating, and using the Sovrin Network. The Sovrin Network is designed and intended to be decentralized so understanding the key influence points and community groups is important.
The Sovrin Network is a global public utility for identity that we all own, collectively, just like we all own the Internet.
When I say Sovrin is "public," I mean that it is a public good that anyone can use so long as they adhere to the proper protocols, just like the Internet. Sovrin is created through the cooperation of many people and organizations. Enabling that cooperation requires more than luck. In Coherence and Decentralized Systems, I wrote:
Public spaces require coherence. Coherence in Sovrin springs from the ledger, the protocols, the trust framework, standards, and market incentives.
I’m really proud of this paper. It’s my attempt to further a new model of media effects that takes into account active audiences, media messages, and technological affordances. I focus on conservative audiences for fake news as a case study.
Basically: People share fake news because it furthers partisan narratives that are promoted by mainstream (mostly) conservative media and expresses personal and political identity.
Most fake news isn’t political, but sensational. Still more is created to be polysemic and appeal to people across the political spectrum in order to increase viewership (and therefore money).
Conservative fake news doesn’t exist in a vacuum. Much of it builds on “deep stories” that have been present on Fox News for decades.
Years ago we were sharing stories about our children. I was recounting to Natalie my favorite funny stories about her. She share with me a funny story about Miles. This little animation is my attempt to keep that memory in animation form.
The three core IETF Token Binding Specifications have been sent to the RFC Editor, which means that their normative content will no longer change. It’s time to move implementations to version 1.0! The abstract of the Token Binding over HTTP specification describes Token Binding as:
This document describes a collection of mechanisms that allow HTTP servers to cryptographically bind security tokens (such as cookies and OAuth tokens) to TLS connections.
We describe both first-party and federated scenarios. In a first-party scenario, an HTTP server is able to cryptographically bind the security tokens it issues to a client, and which the client subsequently returns to the server, to the TLS connection between the client and server. Such bound security tokens are protected from misuse since the server can generally detect if they are replayed inappropriately, e.g., over other TLS connections.
Summary: I spent almost two weeks talking with people about self-sovereign identity in Switzerland and India. I'm more excouraged than ever that self-sovereign identity holds the key to real change in how we live our digital lives with security, privacy, and dignity.
I'm just finishing up my travel to Switzerland and India to talk about self-sovereign identity. The trip was amazing and full of interesting and important conversatons.
The TechCrunch event in Zug was very good. I was skeptical of a one-day conference with so much happening in a short time, but thanks to great preparation by those running the show and all the participants, it exceeded my expectations in every way. I spoke on a panel with Sam Cassatt of and Guy Zyskind from Enigma. Samantha Rosestein was the moderator.
Well, in a twist of fate that I am still bemused by, I am in Microsoft-land now and this fact has led me inevitably to my first Windows install since about 2008. It went pretty well, except that I didn’t have the recovery key for the previous installation, so had to do a scratch install. You’d think it would be easy, since they give you a tool that does all the hard work! All you need is a USB drive of at least 8gb to become the installation media.
But then you put in your larger-than-8gb USB drive and the program says “Your USB must be at least 8gb!!”. You reformat, you think “Maybe I need FAT32”, etc. No luck. All roads lead to the mysterious 8gb error, even when your USB drive is empty and large.
The Security Event Token (SET) specification is now RFC 8417. The abstract describes the specification as:
This specification defines the Security Event Token (SET) data structure. A SET describes statements of fact from the perspective of an issuer about a subject. These statements of fact represent an event that occurred directly to or about a security subject, for example, a statement about the issuance or revocation of a token on behalf of a subject. This specification is intended to enable representing security- and identity-related events. A SET is a JSON Web Token (JWT), which can be optionally signed and/or encrypted. SETs can be distributed via protocols such as HTTP.