NOT DOING THIS: RE: using ASN.1 formats for WebID description

no. nothing to do with the webid and/or a webid URI in a client cert pointing to a .pfx file vs an rdf/foaf card (though I too thought of that).
 
To go through the user experience of using a webid protocol run, lets make it really easy FOR FRIENDLY MEMBERS WORKING WITH THE INCUBATOR to now use a server supporting (i) the webid protocol and (ii) doing access control. Total requirement for user to repeat the experiment is: load a .pfx file into browser, downloaded from web - each one tied to a use case experiment.
 
Yes: the target is 200 developers lurking on the list, only 10 of which these days can program ssl libraries (sigh).
 
I want to convince them that the NOTION of webid protocol (a self-asserted foaf card drives access control, via integration with the ssl handshake) is viable. This is the thesis. Its the same thesis as self-asserted infocards (which were a total flop, and which counts against us in the web-mind). Assuming we believe that webid protocol offers something more than that in the technology of infocards, we can assume the thesis is viable.

Assuming we believe in self-asserted foaf cards signalled via ssl handshakes, then we have to see if the browser faff inherited from 1995 is sufficient or needs to be changed. This includes : the cert dialog needs improving, the cert dialog should be server controlled, the client cert should be exchanged under confidentiality, the finished messages should be available at server APIs, ... These are some of the use cases to be distinguished and then be made subject to easy experimentation (using the pfx file trick). Then we can engage in some decision making on the SSL side of the protocol.
 
perhaps we need two streams of activity in the incubator : folks specialised on the SSL side , and folks specialised more on the FOAF side. its the confluence of these two, after all, that seems to be the basis of our saying that we can now do better than self-asserted infocards.
 
 
> Subject: Re: using ASN.1 formats for WebID description
> From: henry.story@bblfish.net
> Date: Wed, 26 Jan 2011 20:25:07 +0100
> CC: danbri@danbri.org; public-xg-webid@w3.org
> To: home_pw@msn.com
> 
> Ok so you want to allow there to be a ASN.1 based representation
> at the WebID URL, in addition to the RDFa, RDF/XML, and other
> representations in section 2.3 of the current spec
> 
> http://www.w3.org/2005/Incubator/webid/ED-spec-20110121/
> 
> Some things that would be required:
> 
> 1. To have a format that allows multiple keys in the file
> (so a user can have multiple certs, one for each browser)
> 2. A format that is widely used by many tools, I think people 
> claimed PEM was
> 3. A way to add metadata from that file to richer versions of
> the file. A seeAlso to the RDFa (that's html marked up
> with RDF) representation or another access controlled file
> 4. the semantics of such a file format. There is no GRDDL for
> ASN.1 yet, and so this would require some work
> 
> When you speak of this helping new users trying to understand the
> protocol, you of course mean *developers*. And not any kind of 
> developer, but security tuned developers, with a liking of command
> line tools, who feel more comfortable seeing ASN.1, written out in
> a special version of BASE-64, wrapped with headers. 
> 
> Mom and pops users would of course never go close such files, and no
> company with a support department would ever want them to. User 
> want their WebID to land them on a page with pictures and human 
> readable text, with forms they can edit. They want to be able to
> change their picture with a point and click form.
> 
> Browsers will want much richer formats that what is possible in ASN.1
> For example I can imagine a very good browser enhancement, where the
> browser would fetch the graph from the WebID found in a cert in order
> to improve the cert selector by filling it up with information from the
> graph: say the picutre or logo of the user, his name, sex, ... I can
> also imagine the browser showing the user which cert he is using on each
> site and giving him a link to his PersonalProfile (WebID). Clicking this
> he could edit all his information.
> 
> Now the protocol we have makes it completely possible to have what
> you want. I would be interested to see if that really makes some 
> people want to deploy WebID more, or if this is just a way to sidetrack us
> into supporting and maintaining an old format. It is difficult to say.
> 
> I would not be against putting some proposal on the wiki for something 
> like that. We can then see how much enthusiasm it generates in terms
> of real implementations. And we can also document the pros and cons in
> detail over time.
> 
> Henry
> 
> 
> On 26 Jan 2011, at 18:20, Peter Williams wrote:
> 
> > No. The problem is that a new user tying to understand the protocol material currently has to understand the many steps of getting ready to use the protocol, before seeing it's value.
> > 
> > Folks need to be able to experiment with the core flow, without having to first get their own foaf card, keys, or certs.
> > 
> > Having seen a self-asserted credential scheme in action, they can then get their own credential set using some very, very technical websites.
> > 
> > To be convinced that the core flow is viable, the main use cases need to be on display.
> > 
> > 1 initial access, where cert picker correctly displays
> > 2 return access to same site (no cert dialog)
> > 3 access where cert is itself sent over ssl to hide presentation of webid from snooping (prove using proxy snoop, such as fiddlertool)
> > 4 addressing corporate https snooping points ? By showing they are intercepting? (
> > 5 ...
> > 
> > Don't lead with foaf generators, semweb caching, cert generators, or API info for cgi processes. Ensure the security model is on display, and folks can believe in non ca issued client cert credentials. After all, it's quite a claim...
> > 
> > 
> > 
> > On Jan 26, 2011, at 5:37 AM, Henry Story <henry.story@bblfish.net> wrote:
> > 
> >> What is the problem you are trying to solve?
> >> 
> >> On reading this perhaps too quickly it seems that the problem is how to 
> >> move certificates with private key from one browser to the next. Is this right?
> >> 
> >> Henry
> >> 
> >> On 26 Jan 2011, at 14:17, Peter Williams wrote:
> >> 
> >>> PKCS#x is a series of semi-standards. One of them is about storing keys, certs and cert properties, being defined as a UNIX-era stream using ASN.1 types and associated value notations. The stream is stored by web convention in a file, of extension .pfx. Being a file, it can be referenced by an http URI and downloaded by HTTP retaining (file) type information. If the file is downloaded using a web browser to a local file on a PC file store and then this store is referenced by a (IE) browser using a file: URI, the browser will load keys & associated certs into the key/cert container used by the browser. (Users may well be challenged to know a password.) Once done, web sites requesting the browser's user participate in the webid protocol can induce the browser to show the user a client cert picker/dialog, enabling the user to self-assert a foaf card to the site (for the purposes of access control). The same website can automatically induce the browser to re-assert the same card without the display of the dialog - for some use cases.
> >>> 
> >>> to generate a .pfx file in IE, one "exports" the cert (and associated keys) using the relevant browser application's menu option&preferences. IE has Windows construct the relevant PKCS#x-conforming data stream, and the browser manufactures a local file container for the data stream. I believe Mozilla browser does something very similar, and uses the same stream definition (PKCS#x) for file import/export. Please, just name the file: <something>.pfx to promote the convention.
> >>> 
> >>> The art is now to make 5 really good demo .pfx files. Each of the 5 should lead a novice though a set of experiments that she can replicate, very easily. Each should characterize an important use case.
> >>> 
> >>> The 2 .pfx files I generated 12+ months ago were research-grade use cases and used research grade tooling. They may not be good cases for teaching. 5 well-thought out uses cases and the associated .pfx file would allow the new user to try out the "ideal" use cases, learning about the distinctions being drawn in each use cases as she goes through the list replicating the trials using her browser.
> >>> 
> >>> The 2 .pfx file I referenced could be trials #4 and #5, "advanced". This group needs to decide if the uses cases that they demo are even conforming to the design concept. Are they something to be advocated to new users, even if valid? Arguably, what I was doing is too experimental. The experiments sought to link the 2 certs and 2 foaf cards, showcasing that 2 different foaf cards could be being referenced by 2 distinct webids (stored in 2 distinct certs), where the certs in each case and the cards similarly in each case shared a common RSA public key. This is not a classical use case. A futher experiment built into those trials showed something that might appeal to IETF WG PKIX however. Each of the cert correctly uses certificate policy fields, that are also URIs. The presence of these fields arms (in IE) a feature of the the browser's certificate display dialog: the so-called "issuer policy" button. Press the button, when armed, and a browser will navigate to the resource referenced by the policy URI, using the webid protocol is required.
> >>> 
> >>> Perhaps we each make a foaf card, store it on the web, reference its URI in the cert using our favorite tools, and then export the key/cert stream in PKCS#x file format, calling the resulting file demo<me>.pfx. 
> >>> 
> >>> Then publish the URL to the demo<me>.pfx file. As a group, we evaluate what each trial claims to demo as a use case. Those that pass muster can be sequence into a teaching about ideal use cases, allowing the user to learn one use case at a time. In a trial of each use case, the user can actually replicate the experiment easily - while also seeing the end product of the webid protocol: use SSL to get authorization to access a remote web resource. To help teach, one webid-capable resource server should be exposing 5 access controlled resources reinforcing the use case of the particular lesson. Ideally, this would be W3C hosted in a research space, so the W3C brand carries some weight.
> >>> 
> >>> 
> >>> 
> >>>> Date: Wed, 26 Jan 2011 08:12:18 +0100
> >>>> Subject: Re: test and comment on FOAF+SSL material
> >>>> From: danbri@danbri.org
> >>>> To: home_pw@msn.com
> >>>> CC: public-xg-webid@w3.org
> >>>> 
> >>>> Looking up .pfx I get a wikipedia ref to
> >>>> http://en.wikipedia.org/wiki/PKCS ... are distinctions of version and
> >>>> name here important, or you just mean anything that'll store the info
> >>>> that the relevant user's browser can actually read?
> >>>> 
> >>>> Perhaps say 5 fictional users (whose keys/passwords etc are all a
> >>>> matter of public record) would be useful for testing and exploration.
> >>>> Perhaps avoiding the names 'Alice' & 'Bob'...
> >>>> 
> >>>> cheers,
> >>>> 
> >>>> Dan
> >>> 
> >> 
> >> Social Web Architect
> >> http://bblfish.net/
> >> 
> >> 
> 
> Social Web Architect
> http://bblfish.net/
>