Comments Off on RL “Bob” Morgan passing away

RL “Bob” Morgan passing away

For those who knew RL “Bob” Morgan, below is a link (sent by Mike Gettes at CMU) where you are invited to share thoughts/memories of Bob:

RL Bob provided serious contributions to several key specs, including the SAML2.0 specs.  He was also a key contributor to one of the important whitepapers produced by the MIT Kerberos Consortium.

Earlier this year I invited RL Bob to our 2012 MIT Kerberos conference at MIT but he kindly declined, for obvious reasons.

RL Bob will be sorely missed.

 

Comments Off on SAML2.X (Revising the SAML2.0 Specs)

SAML2.X (Revising the SAML2.0 Specs)

For SAML2.0 developers, users and vendors, it is perhaps worthwhile noting that the OASIS Security Services TC (SSTC) has started the process of revising the SAML2.0 specs.

Here is what the SSTC group has agreed to so far:

  • All approved errata, along with any errata presented to the TC subsequent to the last approval, are to be applied to the specifications, or the specifications may be reworded to include the spirit of the errata identified.
  • All original SAML 2.0 message formats are intended to remain unchanged in the new version except in cases where outright errors existed and were corrected through errata or subsequent specifications. This includes preservation of core XML namespaces.
  • To the greatest extent possible, existing implementations of SAML 2.0 features should be compatible with the new standard, and any areas of divergence should be minimized and clearly identified.
  • Some extensions and profiles published after SAML 2.0 ought to be incorporated in some fashion into the base standard to promote adoption and reduce the number of documents needed to address critical features.
  • Significant changes to the Conformance statements for the standard are to be expected. We do not expect that every new feature or existing extension would be made mandatory to implement.
  • Material related to a variety of threats implementers ought to be aware of should be drafted and incorporated.

Please visit the wiki containing the SAML2Revision plans. The SSTC is seeking input from the broader SAML2.0 community.

 

Comments Off on Technical Trust

Technical Trust

 

So the topic of “trust” always generates a million emails on various lists.  Rather than rolling-up my own definition, I thought I’d borrow a good definition from the Trusted Computing Group community (courtesy of Graeme Proudler of HP Labs, UK).

It is safe to trust something when:

  1. It can be unambiguously identified.
  2. It operates unhindered.
  3. The user has first hand experience of consistent, good, behavior.

The definition is that of “technical trust”, namely “trust” in the mechanics of some computation (e.g. cryptographic computation, etc). In this case it refers to the TPM hardware. Note that “unhindered operation” is paramount for technical trust.  This is still somewhat of a challenge for software (eg. think multi-tenant clouds and VMs).

 

Comments Off on UMA, OpenID-Connect & OAuth2.0

UMA, OpenID-Connect & OAuth2.0

Eve Maler has devised a very useful diagram (for our Google techTalk presentation), comparing the features and intended purposes of OAuth2.0, OpenID-Connect and UMA.  Interestingly, the diagram also shows what can be achieved using the venn combinations of two out of three technologies.

 

Comments Off on A market for leakage in derived identities

A market for leakage in derived identities

At lunch today Sal summarized in one sentence what I have been trying to express for the last couple of years:

There is a market out there for leakage in derived identities (in the Internet)

What we had been talking about was the (inevitable) need for something similar to what the Jericho Forum folks call Core Identity. In simple words, this is the notion that every entity/person should have a “main” secret identity (like a confidential SSN number), from which other usable identities (personas) are derived via a one-way function. (See the Jericho Forum “Identity Commandments”).

The question was how and who was going to manage the issuance and maintenance of the core identities of US citizens. Since the US federal government was the issuing authority for social security numbers in the US, one possibility would be for the US federal government to be the issuing and maintenance authority for core identities (independent of whether the day-to-day managing was actually outsourced to private sector organizations).

The “leakage” here refers to the obtaining (e.g. scraping off the Internet) of pieces of information about one of my persona stemming off my core identity. For example, in my “home-persona” the location of my house may be of interest to advertisers who are doing target-marketing in my neighborhood. We can call this “leakage” because I never authorized the release (and usage) of my home-persona to the relying party (i.e. the marketing company).

 

 

Comments Off on Blogging (again)

Blogging (again)

I’ve decided to start blogging again, this time around on digital identity on the Internet and security in general. Why:

  • Promote identity related efforts/projects that I think are on the right track and have promise: the User Managed Access (UMA) community is addressing a problem that goes one step beyond identity federation and SSO, namely the problem of resource sharing on the restful web.
  • Concern about the direction of the “identity industry”: lots of things.
  • Thinking aloud: hopefully other folks can confirm if “I’m missing something here” (e.g. industry doing something silly or just re-inventing the wheel again) or simply correct me if I’m way off.
Newer Posts