Shared publicly  - 
Using Facebook as an Identity Provider for the WebID protocol

The issue of flexible and verifiable identity is an InterWeb scale problem. WebID and its authentication (verification) protocol offer a viable and scalable solution by leveraging:

1. Internet Architecture

2. Web Architecture -- URIs

3. Linked Data -- directed graph based "whole data representation" that leverages de-referenceable URIs.

Here is a simple step-by-step guide that demonstrates how Facebook users can achieve the following, right now:

1. Obtain an Info Card (X.509 Certificate / Security Token) with a WebID watermark

2. Verify the Info Card.

Steps to Generate your Info Card

1. In the web browser of your choice (Safari, IE, or Chrome are easiest, as they work with OS-native keystores, but you can also use Firefox, Opera, or others), go to <>.

2. Click the Facebook button.

3. Log in if prompted.

4. You'll see your name and a Facebook Graph API based URL. Click "next" to proceed to the next stage.

5. The "Certificate details" page now loads, using your Facebook Graph API URL (or a proxy/wrapper URL if you choose this more portable option) as the WebID watermark for the pending certificate. Change your "name" here, if you have or will have multiple certificates installed in your OS or browser -- so you can tell which is which, when prompted to provide an identity. If you like, you can also add an organization name or email address in the relevant fields.

4. Choose any Identity option, Key Strength, and/or Cipher (the defaults are fine), and click "Next".

5. On "Select signer of the Certificate," leave "Issuer" as "Self-Signed" and click "Generate".

6. On "Select format and store option", you must enter a password before proceeding. "PKCS#12 file bundle" (that is, a .p12 file you can persist on any filesystem) is the most flexible storage option. Click "Download" to save the .p12 file (named with the FriendlyName) to your local disk. Or pick the Browser PKI option which results in a certificate request exchange between your browser and the host operating system or native browser keystore/keychain.

7. Click on the "Persist in IdP dataspace" button.

8. You are now presented with a tabbed interface that provides a variety of options for persisting your Info Card's fingerprint, to a number of data spaces. In this case, click the first tab, labeled "Store using OAuth" (this really means, "store to the OAuth authenticated data space from the Facebook bonding page"), and click the "save" button.

9. At this stage, you will be able to see a Facebook post with hashtag #WebID that includes your Info Card's fingerprint and its associated crypto hash function (MD5 or SHA1).

9. In your local OS filesystem UI, open (typically, double-click) the local .p12 resource (file) and your OS should commence the process of persisting the content to its native keystore or keychain. (Generally, you can take the defaults in all prompts, until saved.) (If using Firefox or Opera, you must persist this content to the Browser's keystore.)

Steps to Verify Identity via Info Card with WebID watermark

1. In the web browser of your choice, go to <> -- a simple HTML-based WebID verification app.

2. Click on the "check" button.

3. If prompted to choose an Identity, select the one you named in step 5, above.

4. Verification will either pass or fail.

What just happened?

You've just created a verifiable identifier for yourself, that's been used as a watermark in an Info Card (something like a digital parallel to your passport or drivers license). You have also verified this identifier (i.e., acted like the passport or license office).

Passport Issuer

This is what happened when you generated the Info Card via the HTML wizard. To be precise, right up to the point where you saved the PKCS#12 (.p12) resource to your local disk and then imported it into your local operating system's keystore or keychain.

Passport Office

This is what happened when you clicked on the "Persist to IdP dataspace" button. Basically, the generator used your Facebook Graph API URL (an HTTP-based URI, serving as a WebID) to locate a data space (in this case, the one hosted by Facebook) into which it placed the Fingerprint (a crypto hash) of the Info Card you just generated.

Identifier Verification

This happened when you invoked the HTML-based verification application at <>. The mechanics are as follows:

1. Clicking the "check" button redirects to an https URL.

2. You are challenged to present an Info Card as part of the standard SSL/TLS handshake.

3. When the standard handshake completes, an additional verification step occurs, whereby this WebID protocol-compliant application (conventionally referred to as being in the role of Relying Agent) performs the following steps:

a. De-references the WebID in the Subject Alternative Name of the Info Card.

b. Locates a data object (a graph encapsulator) at an address.

c. Checks to see that it can find a Fingerprint for the certificate used to successfully complete the standard part SSL/TLS handshake; at this point you have success or failure.

Why is this important?

The virtues of WebID have never been in doubt, once the concepts behind the protocol are understood. What's eternally challenging with new technology is how you roll it out to a community of existing users that are already aligned to existing applications and services.

This very simple process grants every Facebook user the opportunity to acquire a self-signed Info Card, en route to exploiting the immense utility of verifiable identity at InterWeb scale.


1. -- using LinkedIn as a WebID Identity Providers (IdP) oriented data space.

2. -- using WordPress and other AtomPub compliant blog platforms as WebID Identity Provider (IdP) oriented data spaces.

3. -- using Twitter hosted posts (Tweets) as WebID Identity Provider (IdP) oriented data spaces .

4. -- additional information about WebID.

5. -- WebID Wiki

6. -- using WebID to kill off email spam via S/MIME + WebID protocol.

#WebID #LinkedData #SemanticWeb #Security #Privacy #Nymwars #Identity #Facebook
Mark Wallace's profile photoDavid Lewis's profile photoMelvin Carvalho's profile photoKingsley Idehen's profile photo
Finally, the first true "Web Scale" Identity system has arrived. Congrats Kingsley!!
Are there directions for using google as an identity provider for the WebID protocol?
+Mark Wallace -- GMAIL is the only option right now via Webfinger. Thus, you can place the mailto: scheme URI associated your GMAIL account into the Certificate Generator, then click on "lookup", and you'll see the effects of Webfinger kick in. Whenever G+ releases an API with "write" options, we'll add it to the WebID IdP list in nano seconds :-)
any attempt to verify the email address results in a "You are not authenticated."
That's what's failing - I get an email from that service, I click on the enclosed link (with some trepidation - we'll discuss the phishing/URL masking implications elswhere) and the resulting webpage informs me that I'm not authenticated.

The most recent time it did check my local certificate store, but I don't want to grant an external party access to either of the certificates stored there.
+Mark Wallace -- remember, WebID is all about "proof of private key possession" + trust logic. You have to sign messages using your private key, that's what the interaction is about, no more no less. Also remember, you can also just make another certificate or use a browser that doesn't use the OS keystore/keychain e.g. Firefox and Opera .
Aha - user error - how do I generate that private key? I guess I misunderstood the instructions in your post; I thought that key generation was triggered during the process. Let me go and review. (Let's consider that all the "read instructions before beginning" jokes have been made </grin>)
+Mark Wallace -- the process should generate a certificate for you. In addition, it applies "proof of private key ownership" logic to your chosen Identity Provider Space by persisting specific claims that only you can ultimately verify, cryptographically within an SSL/TLS session.

Re. S/MIME, we've just enhanced it with WebID :-)
How can this be implemented in environment like a hospital where clinical staff may be using many workstations as they do their rounds? #hscm
Lots of ways. Each doctor has a pass and a pin number. The pass e.g. wireless can use pkcs11 to identify themselves. When they get to the work station they then have to enter their PIN to access data.
Add a comment...