[foaf-protocols] WebID - mandated syntax or market solution? was WebID Incubator Charter draft

peter williams home_pw at msn.com
Sat Dec 18 01:35:04 CET 2010

For years folks supported DigitalIDs. Well, actually, hardly anyone did that literally - because every "profile" of a cert/DigitalID had different extensions, with unique value types and syntaxes for the values. 10 years after the dissolution of the firm, you still see Netscape extensions in DigitalIDs, that many cert processors just ignore (as intended by the ISO committee)

DigitalIDs have several transfer-encodings. Though value-encoded to DER for the most part (vs BER), folks stores the binary in variety of forms. These were mostly variants of the PEM 1421 message format, suitably broken in about 10 different ways depending on the incompetence of the programmer hacking on a bit of base64 code. In some cases, folks included multiple certs in a transfer-encoding. One infamous format was the Microsoft .spc file (which also wrapped the chain of certs in the PKCS7 value syntax).

On the SSL wire though, SSL certs are always transferred in the value-encoded form. Formally, TLS breaks this rule, allowing negotiation of cert format. I've never seen it used in the civilian web. Im led to believe its used when half-upgrading older phones with fixed crypto/cert chips so they can do SSL and IP in general when performing call setup with newer SIP gateways.

Now, certs have since day 1 been necessarily de-referencible to the directory record/object named by the subjectDN field. Providing that that multi-attribute subect name could be reduced to a DN (using a directory), one could pull the signed record from the master directory agent, itself located using the DN and the usual local resolver hints. The directory access protocol used the ISO layer 6 protocol, which had formal content negotiation (called presentation data contexts, if anyone cares). The formats of the attributes and their values and their syntaxes were by 1992 stored in the schema nodes in the directory too, if you had a metadata-aware UA. Microsoft AD is a variant of all this, polished up rather well to suit a mass market.

One can obviously perform a variant of this process, when the subject name of the cert has URI name-form, uses HTTP to de-reference the URI, and then pulls a FOAF card (by content negotiating RDFa, say). When I had URI added to certs, I had no concept of a FOAF card. The URI simply named X, and had document referencing power. It was made a URI so (old) URNs could also serve as naming authorities, rather than the URLs of the web. This is how we thought in those days...

If the [modern] URI has metadata attached to it indicating the verification *protocol*, then it MAY be a webid. It is validated to be one when the indicated webid protocol confirms that it is authentic.

In the equivalent directory object world, the verification procedure was specified in X.509 (the bit on challenge response handshakes, vs certs). If one performs the verification, cert validity is performed, based on using particular attributes in the directory record. The procedure is complex, and recursive, involving chains of certs, various object  classes and various attributes. Though particular services are mandatory, their protocols are not. One can use the OSI stack , or the IETF-centric ldap. It's irrelevant, so long as the protocol delivers the semantics of the directory abstract service.

Obviously, the webid world does exactly the same thing with the semantic web rather than a directory, and leverages the the various data dictionaries specified by this group for classes, attributes, values, and syntaxes. There were/are tuned up for RDFa, on the basis that most folks are going to want to markup their homepage in HTML, rather than concoct RDF in some or other math-like or XMl-like notation.

Nicely, the RDFa markup feels like micro-tags, when you use them.

Then there is stuff about trust chains iun the record of this group: the semweb version of the X.509 cert chain procedures. Im not whether that material is or is not a part of this proposal. Architecturally, a webid protocol DOES imply a trust chaining procedure, performed during verification, simply because its implied by use of certs in any and all webid protocols. Arguably, some or other trust  chaining scheme (conforming to a trust framework that can capture how openid and samle and OATH also use trust scheme) is therefore "part of" a webid protocol.

That’s my thinking, as of today. 

-----Original Message-----
From: foaf-protocols-bounces at lists.foaf-project.org [mailto:foaf-protocols-bounces at lists.foaf-project.org] On Behalf Of Jirí Procházka
Sent: Friday, December 17, 2010 3:54 PM
To: foaf-protocols at lists.foaf-project.org
Subject: Re: [foaf-protocols] WebID - mandated syntax or market solution? was WebID Incubator Charter draft

On 12/17/2010 09:20 PM, Kingsley Idehen wrote:
> On 12/17/10 1:32 PM, Jiří Procházka wrote:
>> No, you are missing the point, this isn't about RDF at all, I 
>> mentioned RDF only because it would be convenient if the mandated 
>> syntax was also RDF serialization. Please lets not talk about RDF any more.
> Good.
>> The issue is whether the "supports WebID" should mean "supports the 
>> WebID Protocol with at least syntax XYZ" or just "supports the WebID 
>> Protocol, eventhough it may speak to you in syntax which would be 
>> incomprehensible to your software, thus spewing a confusing error 
>> message".
> It speaks the protocol. The data that the protocol operates on should 
> be structured such that: an Entity (Subject), its Attributes 
> (Predicates), and Attribute Values (Predicate Objects) are clearly 
> discernible to machines and humans.
> Representations should be negotiated between clients and servers.
>> Some people just want to have the guarantee the latter won't happen - 
>> exactly the people I said you weren't considering in your 
>> let-the-best-syntax-win idea.
> HTTP lets you negotiate Structured Data Representation.
>> Also even if we fairly soon settle on a set of syntaxes which would 
>> cover 99% of WebIDs in the wild like Henry hopes, still this would be 
>> a "set of syntaxes" which is rising the implementation costs compared 
>> to having to support just the one syntax (if you are willing to 
>> sacrifice the possible advantages of the other probaly newer ones).
> See comment above re. content negotiation.
>> Realistically, there will be a range of implementations from feature 
>> and syntax support rich, to bare bones implemetations *both on the 
>> publisher side and the client side*. If we want even the bare bones 
>> implementations to be interoperable, they have to use the same syntax.
> They have to grok the model and negotiate preferred structured data 
> representations.
>> Otherwise the nice and striking "WebID" name is just good to use on 
>> academic papers and conferences.
> WebID isn't popular in academic circles. Most implementations to date 
> aren't from academia :-)
> Kingsley

Sorry, but this reply makes me feel like I am talking to a wall. This is nothing new to me, what you say it basis for Linked Data which I am familiar with in detail for a couple of years, and you have been infusing most of your emails with it in one form or another. Lets just agree we know what we are talking about and get to the point:

Do you agree the "WebID" name could be used, besides as the protocol name, for something like a certificate (think
http://validator.w3.org/docs/help.html#icon) which guarantees to an end user the software/service is usable in some way? (when it is not offline of course)

Do you agree there are higher demands on reliability of protocols then anything else? Do you think if for example with DNS protocol while answering your query each participating nameserver could return "syntax not understood" error returning it to you as final answer would be good?
Please name some protocols which do this (syntax conneg - they are just defined as logic - the model, like you wish).

Do you realise your reqirement "They have to grok the model and negotiate preferred structured data representations." puts much larger strain on potential adopters over whole time they attempt to support WebID the best, implementing new syntaxes over time as they gain popularity, yet still failing to be 100% interoperable, instead of my requirement of having to support at least one particular syntax, which they can implement once and forget about it, being 100% interoperable with valid WebIDs?


More information about the foaf-protocols mailing list