RE: WebID and Friends -- a silent movie demonstrating what's possible

So what does the multi-protocol world gain us? Let’s think, out loud.

 

One of the things I learned about OAUTH recently was the difference between traditional and modern perspectives. Traditionally, the handshake distributed a label for the access token and an accompanying opaque secret - to be used by a client in a client/server authenticating itself in  subsequent API bindings(s). In the modern views (plural), the handshake generalizes the access token from being merely a name into being a “delegated token” - in some or other structured object notation. Obviously, the difference is that the modern view has discarded the notion that the access token concept only has one purpose: of naming the *opaque* shared secret. There are “plural” modern view because there are “multiple” notations and data types definable for this “structured” access blob. One thinks of the Azure-supported SWT, for example. One thinks of the JWTs, too. What’s the betting that Microsoft/IBM have already taken their ws-security/ws-trust proof tokens and re--specified them, now in the notation of JWTs?

 

So, why cannot the IDP (aka OAUTH provider) be sending - as “an access token in a structured notation” - some well-defined ASN.1 object? For example, why not send a .p12 file (i.e. structured object representing a private key with associated X.509 cert chain(s))?

 

If the OAUTH provider is generating the .p12 file on the fly as intends said stream to be the “structured access token”, surely the end-user certs within *could* be being provisioned by the IDP with the desired URI SAN - per the webid spec. Surely, the access secret that accompanies the access name/structured-token could be the password that enables the intended recipient to unwrap .p12 file?

 

IETF is going to some considerable lengths to re-invent - with encrypted JWTs - what already exists in the .p12 file. To be fair, the framework of signing and encryption primitives for JSON has wider scope than just “certified private key distribution” - implementing de novo the PKCS7 signing and encryption primitives for structured objects. But, in just the scope of what .p12 is for, I’m not sure swapping bit formats from ASN.1 to JSON is adding much (with security engineering inevitably going backwards, as all the vulnerabilities due to actual JSON libraries are discovered and eliminated over the next few years).

 

Now, you might say... but didn't we just LOOSE the modern OAUTH’s “delegation” world by distributing a .p12 file as the access token - that very thing that modern access tokens enable? Didn't we just loose what delegation facilitates -  support for n “derived key” method ...that are tuned to the needs of upper-layer security protocols? 

 

Perhaps not, since certs chains easily support delegation concepts, too - as standardized even by IETF in the OCSP RFC. The chain(s) of certs in the .p12 file could contain in one chaining path that which chains up to (delegates from) the subscriber’s public key, present in a foaf card sitting out there on discoverable web endpoint. Other paths embedded in the file could be chaining up to the IDP’s trust point (sitting in DANE record, delegating authority from DNS and DNSsec)

 

One gets a fair amount of “survivability”, using only classical key distribution knowhow for asymmetric keys. Lots of crypto politics would be sorted, since the status-quo would be unaffected. Obviously server side client (e.g. crawlers) easily get the ability to now do webid type authentication, to the linked data world. Those crawlers can be now “acting for” a browser user, of course, given the whole OAUTH idea.

 

Sent from Windows Mail


From: Kingsley Idehen
Sent: ‎October‎ ‎27‎, ‎2012 ‎2‎:‎39‎ ‎PM
To: WebID XG, public-rww@w3.org
CC: Peter Williams
Subject: WebID and Friends -- a silent movie demonstrating what's possible



All,

A silent screencast (recorded screen interactions) demonstrating the use 
WebID, OAuth, and OpenID for authentication. I inadvertently forgot to 
include the basic digest authentication demo.

Here's what the screencast covers:

1. login authentication
2. 3rd party account binding -- so post authentication I use OAuth to 
bind my other accounts to my ODS account.

Link: 
https://dl.dropbox.com/u/11096946/ODS%20Demos/screencasts/ods-javascript-authentication-and-account-binding-demo-silent.mov 
.

-- 

Regards,

Kingsley Idehen 
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com

Personal Weblog: http://www.openlinksw.com/blog/~kidehen

Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about

LinkedIn Profile: http://www.linkedin.com/in/kidehen