Andre Durand

Discovering life, one mistake at a time.

Archive for September, 2004

Rise of the Attribute Horde

September 21, 2004 By: Andre Category: Ping Identity

I read a great Editor’s note in CIO Insight this month on the effective end of privacy as corporations build massive customer databases in an attempt to better understand how, who, when and what to sell to people. In federation terms, I call this ‘attribute-hording’, the concept that companies aggregate our attributes and then leverage the aggregation of these attributes to build ever more complex algorithms for predicting our behavior. While I’m generally OK with trading privacy for convenience on a per company basis, I’m less enthused about allowing that implied privacy relationship to be federated without my knowledge — but that’s another topic.

I wanted to hone in a particular line of business which specializes in aggregating our personal attributes for the purpose of resell. I think these companies are particularly dangerous, as they become concentrators of data which could be used in a variety of unpredictable ways, most of which not necessarily beneficial to the attribute owner him/herself. Unfortunately, they already exist in many forms, and it’s already big business in a variety of markets, so I doubt there is little we can do to stop the ones that seek to aggregate attributes that we consider to be private.

Federated Identity & PKI Collide

September 17, 2004 By: Andre Category: Ping Identity

We’re coming across more and more initiatives where PKI and Federation seemingly overlap. As is the case with most technologies, there is some overlap both in use-cases and where the technology can and will be applied. We took the time the other day to summarize some of the key differences between the two, attempting to outline where they were strong, where there was overlap and where there wasn’t. A summary of these findings is listed below. 


  • PKI and Federation are not mutually exclusive.

    • Federation leverages PKI heavily for server-to-server and client-to-server security.

    • PKI is particularly good for enabling a strong authentication which can then be federated. Federation is authentication method agnostic.

  • While PKI can provide a vehicle for attribute distribution, it is not particularly good at accommodating the more dynamic use-cases where authorization decisions will be made on-the-fly (via rules-based engines).

  • To the contrary, federation is particularly strong for enabling a scalable infrastructure for the sharing of dynamic attributes (attributes which are more dynamic than those carried with long-lived credentials).

  • Leveraging PKI for strong-authentication of the end-user is likely a good thing in the long-term. Leveraging the strong PKI authentication for session-based assertions (aka — not performing strong-auth everywhere, but instead porting that strong-auth via federation assertions within a particular user session) is also a likely outcome of the convergence of the two technologies.





  • Authentication-method independent

  • Authentication Assertions based upon authentication done outside of pure-federation protocols.

Used for Strong Authentication with Certificate granted through:

  • Registration Authority which performs Identity Proofing

  • Certificate Authority Manages Policies

High assurance and high security

Longevity of Credentials / Assertions

  • Federation particularly good for short-lived identity-related assertions (via tokens)

  • Life of an assertion typically short (minutes) – i.e. “a session.”

  • PKI particularly good for enabling long-lived tokens — in the certificate

  • Life of the certificate can be several years

Primary Utility

  • Federated authentication represents a methodology for extending authentication to multiple ‘replying parties’ via short-lived authentication assertions.

  • PKI represents a methodology for binding an entity to a long-lived credential for the purposes of enabling strong-authentication at the point of use.

Where Authentication is Performed

  • Authentication provided at Identity Provider/ Credential Service Provider  (IdP/CSP) according to methodology in use at that Identity Provider  (could be password, token, certificate, or other)

  • Authentication performed at Service Provider / Relying Party based on root CA (in cert), expiration date (in cert), and check against revocation (CRL or ODSP)

Where infrastructure is Dynamic vs. Static

  • Federation provides for a dynamic infrastructure, ie trust of the IdP/CSP can established at any time through adding IdP/CSP to federation list

  • Static infrastructure, ie certificate chain to root contained in the certificate; SP/RP must know and trust the root

Anonymity & Pseudonymity

  • Enables anonymity / pseudonymity where access can be granted based on ‘role’ rather than on individual identity

  • Pass assertions containing identity ‘handle’ to receiving site

  • Identity is represented by a unique ID within the certificate

  • Use certificate identity for authentication at all SP/RPs

Handling of Attributes

Federation is particularly strong at providing an infrastructure for flexible, dynamic attribute sharing:

          multiple attributes can be in any assertion

          attributes can differ by site

          attributes can be dynamic values

          enables rule based policy based on attributes

Attributes placed in certificate at time issued;

          no easy/scalable method for updating static attribute list


Cost to Deploy

Server infrastructure cost and complexity does exist. However, deployment costs and complexity when extended to end-user does not scale proportionately the same way as PKI does for the same use-cases.

Can be expensive and complex to deploy and maintain all the way to the end-user. Appropriate where security requirements are high and static attributes not an issue.

Summary Findings





Very good for assertions based on a recent/session authentication


Very good strong authenticator


Makes sense for re-use of authentication across multiple domains


Makes sense for secure access to a single domain


Most appropriate for internet-scale applications where very high volume and dynamic infrastructure are considerations


Most often used method to protect server-to-server or client-to-server conversations


Dynamic attribute support


Weak attribute sharing support


Enables dynamic partnering


Requires pre-determined trust list


Short-lived token

Persistent credentials