W3C home > Mailing lists > Public > public-xg-webid@w3.org > January 2011

RE: WebID-ISSUE-6 (bblfish): using ASN.1 formats for WebID description [WebID Spec]

From: Peter Williams <home_pw@msn.com>
Date: Fri, 28 Jan 2011 06:06:43 -0800
Message-ID: <SNT143-w37296BAA4CBE151FB274FC92E10@phx.gbl>
To: <public-xg-webid@w3.org>

Its not an impressive writeup. But, it releases tension.
 
I hoping at 20, W3C is mature enough to join the crypto space, which is very political and more than a few hundred  years old. My feeling is that this organization will be a useful addition, at this social juncture - having navigated web politics and more importantly having succeeded to evolve the *form* of the debate so the users of the web could find means of evolving themselves. It has something to teach (very scalable politics), and some technology to add (semweb). 
 
 
> To: public-xg-webid@w3.org
> From: sysbot+tracker@w3.org
> Date: Fri, 28 Jan 2011 07:30:45 +0000
> Subject: WebID-ISSUE-6 (bblfish): using ASN.1 formats for WebID description [WebID Spec]
> 
> 
> WebID-ISSUE-6 (bblfish): using ASN.1 formats for WebID description [WebID Spec]
> 
> http://www.w3.org/2005/Incubator/webid/track/issues/6

> 
> Raised by: Henry Story
> On product: WebID Spec
> 
> There may be some reason to allow ASN.1 based representation
> at the WebID Profile Document, 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. PEM is.
> 3. A way to add metadata from that file to richer versions of
> the file. A seeAlso to other documents such as the RDFa 
> (that's html marked up with RDF) representation of the profile document
> [ ie: a <link rel="alternate" in Atom lingo ] or another access controlled file
> where more information is available [ a seeAlso link of some type]
> This could be put in the document or in the header of the returned document
> though putting it in the header would be a lot better given that one would
> want things to be as transparent as possible. (setting headers can be difficult)
> 4. the semantics of such a file format. There is no GRDDL for
> ASN.1 yet, and so this would require some work
> 
> So instead of an RDFa Profile Page an HTTP GET on the WebID could return
> something like the following file, which contains two certificates in PEM format
> with the same WebID:
> 
> [ for info on PEM see 
> http://serverfault.com/questions/9708/what-is-a-pem-file-and-how-does-it-differ-from-other-openssl-generated-key-file-f

> http://tools.ietf.org/html/rfc1421 ]
> 
> 
> ✄⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯✄⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯✄⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯✄⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯✄
> 
> 
> -----BEGIN CERTIFICATE-----
> MIIDkjCCAvugAwIBAgIQTNDvJII8IoLQAqZOZUIrOTANBgkqhkiG9w0BAQUFADBj
> MREwDwYDVQQKDAhGT0FGK1NTTDEmMCQGA1UECwwdVGhlIENvbW11bml0eSBvZiBT
> ZWxmIFNpZ25lcnMxJjAkBgNVBAMMHU5vdCBhIENlcnRpZmljYXRpb24gQXV0aG9y
> aXR5MB4XDTExMDEyMzE3MzU0NFoXDTEyMDEyMzE5MzU0NFowgZYxETAPBgNVBAoM
> CEZPQUYrU1NMMSYwJAYDVQQLDB1UaGUgQ29tbXVuaXR5IE9mIFNlbGYgU2lnbmVy
> czE7MDkGCgmSJomT8ixkAQEMK2h0dHA6Ly9sb2NhbGhvc3Q6ODA4MC91c2VyL2Fk
> bWluL3Byb2ZpbGUjbWUxHDAaBgNVBAMME0FkbWluQGNsZXJlenphLnRlc3QwggEi
> MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDxtw9nBcjSyvBMCmuzcjBJB/NK
> T9+1u8MYvRZ27wjihFgvlC7X6kaVga0GFMw8qrw/kl3OaXgjaATn+6uWx+5Dd1DP
> HTtlybJjw1iYr2ztF7uOH8D9zLQDvBvcueb3jbxd0rB8J1REuFn8FoPSTcFKR6MP
> 37UzaQ6wfr3tjhZfTefTLLPM15ltX9zTPRRhVnAOLiGo0GsRZgIMUSJ7dvnrnYBg
> 471HqkBUuXJaoAJgmRk6f192Lu33zJHVJhyRFNPBfIkKFSCg+Zvsd7xwtrliHzGm
> /a8YLHpGMRATF18o8fuzQ0LCVZLfYVRYTvUfL69momgVj13eaRH6AmkH2SKXAgMB
> AAGjgY4wgYswDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCAuwwEQYJYIZIAYb4
> QgEBBAQDAgWgMB0GA1UdDgQWBBQrDFGH8V/Xa9xzp5R3il/EO+zynTA5BgNVHREB
> Af8ELzAthitodHRwOi8vbG9jYWxob3N0OjgwODAvdXNlci9hZG1pbi9wcm9maWxl
> I21lMA0GCSqGSIb3DQEBBQUAA4GBAKjbuZdkFChvIXTBuUWcKoGa7FZlv9Ki6QVj
> 3mgqGlwu3dbOmXH/RIpNW4SbQzt3Kf2ws6rL9AkCw25J38/3qRIhy5W8xbFKX5nu
> nwaVUKPIWjlviP+D+K0/e7ubLh5mQwLtmn6L+h/dMYPDL25RFx0tOmvhe7Lgfvr9
> myw6bTre
> -----END CERTIFICATE-----
> -----BEGIN CERTIFICATE-----
> MIIDjjCCAvegAwIBAgIQcHZnHdBU1rYrA2KUrJHnATANBgkqhkiG9w0BAQUFADBj
> MREwDwYDVQQKDAhGT0FGK1NTTDEmMCQGA1UECwwdVGhlIENvbW11bml0eSBvZiBT
> ZWxmIFNpZ25lcnMxJjAkBgNVBAMMHU5vdCBhIENlcnRpZmljYXRpb24gQXV0aG9y
> aXR5MB4XDTExMDEyNDA5MjczOVoXDTEyMDEyNDExMjczOVowgZIxETAPBgNVBAoM
> CEZPQUYrU1NMMSYwJAYDVQQLDB1UaGUgQ29tbXVuaXR5IE9mIFNlbGYgU2lnbmVy
> czE7MDkGCgmSJomT8ixkAQEMK2h0dHA6Ly9sb2NhbGhvc3Q6ODA4MC91c2VyL2Fk
> bWluL3Byb2ZpbGUjbWUxGDAWBgNVBAMMD0FkbWluIEBjbGVyZXp6YTCCASIwDQYJ
> KoZIhvcNAQEBBQADggEPADCCAQoCggEBAL9Co45yE8pfs1jA4S7k+2vo33VEb02F
> fqC0WCZEp+tRNQpF8jep3pT3hTqiN9nnJTDVrV9TYJifhLuVy9oj8YyZK7s3al07
> BGGFR1KaywbCcZ3nm7mYDrxaedSkhQXkP99AtjOsUD5LGQvQMgM0/FwosrdcNhU1
> b3wg/y6kzxfK4L/Ie/SjNiBZ7toBtjO1f9Tfx/UhGgVBJeSB+JJLXm+J3VDu3vLX
> d5MdiISlRSQyILSCMH/Oazdk40oYTKHIBM/sYy0FXIDzDikx1QG8jC46t0zWFGQN
> oHN7JAd3Pe0N+engqO6KaRry2DcfUObPmGZ2GOCmnlkbFwH2Wm7aT+sCAwEAAaOB
> jjCBizAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIC7DARBglghkgBhvhCAQEE
> BAMCBaAwHQYDVR0OBBYEFAo+wVGHvD8FYxRMQhu5FdYxOAqXMDkGA1UdEQEB/wQv
> MC2GK2h0dHA6Ly9sb2NhbGhvc3Q6ODA4MC91c2VyL2FkbWluL3Byb2ZpbGUjbWUw
> DQYJKoZIhvcNAQEFBQADgYEALp0V2VDiK6375s9xv11oSIvfLzk4x+ajYv9ElIFi
> KAzWaEEjMnW0B8FdfpjRtqcV7NT8/5I6nGkJxGDxsHFcqG1xWtsK1uQRmImnIUZv
> gpYBqUmc2FMpqXzPbHXrK8XuL71DBXmfmxGciVfWvOvui4QrthYp4GY9JmdNMUIo
> hzg=
> -----END CERTIFICATE-----
> ✄⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯✄⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯✄⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯✄⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯✄
> 
> 
> This could perhaps help developers, especially those with a lot of experience
> with security standards, tools like openssl, and others get to be familiar
> with the basic principle of WebID, without them needing to learn any
> semantic web tools. The people who understand these formats may
> be very influential in getting things started, since it is to them that most
> business people will go when they need answer to a security question.
> 
> Mom and pops users would of course never go close such files, and no
> company with a support department would ever want them to. Users 
> 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.
> 
> But that is not a problem. A security expert, call him Peter, can go
> and start by placing a PEM file at the WebID. If he is careful with
> making WebIDs that can work with future content management 
> then any client that requests the WebID with 
> 
> Accept: application/x-pem-file
> 
> will receive the PEM file, even if later Peter decides he can have
> more fun with HTML5 marked up with RDFa. He need not
> even abandon his PEM files when he makes the switch.
> Clients that would rather have HTML will send out GET requests
> with something like the following header
> 
> Accept: text/html;q=0.8, application/x-pem-file;q=0.3
> 
> and if Peter's server has only pem the pem will be returned, but if it
> has html the html will be returned. (This is known as content negotiation)
> 
> There are many reasons to have more flexible formats that ASN.1 formats:
> - they are human readable
> - keys can be compared much more easily
> - new relations can be added easily (ASN.1 requires one to ask for new OIDs
> at some central committee, somewhere)
> - formats like html suppor FORMS
> 
> The flexibility of RDF or XML based formats can be very useful. They could allow
> browsers to fetch the graph from the WebID found in any of the X.509 certs that
> were created by the user, in order to improve the cert selector by filling it up with
> information from the graph: say the picture 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.
> 
> This is quite feasible in the current protocol. It's just a question if people want
> to work on the language of the text, implement it, test it, and support it.
> 
> 
> Henry
> 
> 
> 
 		 	   		  
Received on Friday, 28 January 2011 14:08:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 28 January 2011 14:08:44 GMT