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 07:30:47 UTC