RE: self-signed

On 19 Apr 2011, at 20:53, Kingsley Idehen wrote:

On 4/19/11 3:16 PM, Mo McRoberts wrote:

> That's really DoD. IMHO. re., any version of WebID that exits this this
> IG. It has zero effect on me (personally) or my corporate entity
> (OpenLink). The only loser will be the WebID protocol itself :-(

Why?

Are you seriously saying that you will _only_ publish your WebID FOAF document through some protocol which isn't http-based?


Please don't respond subjectively to my comments. Just not right. When did I say or infer that? 

Evidently a misinterpretation of “it has zero effect on me/OpenLink” — which I took to mean “if it's released in this fashion, it will have no bearing on us because it will be an irrelevance”. I'm not not sure that meets the definition of “a subjective response” — based on what you said (interpreted correctly or not), I asked for the reasons why.

Even when I said, with clarity, non of this has any bearing on me personally, or my corporate entity OpenLink Software, you gut response is the question above? 

Because it wasn't “with clarity” in the slightest, especially following a multitude of posts about what ODS does and doesn't do, so perhaps you'll forgive the unintentional misinterpretation.


WebID is Dead on Delivery (DoD) if its a vector for a specific scheme instead of a vector for InterWeb scale identity that leverages the collective prowess of:

1. URIs

1a. Well-defined and universally-implemented resolution mechanisms for those URIs.

2. Structured Profiles
3. Trust Logic.

The WebID that you and Henry seem to speak of is one that might someday deliver on 1-3 above across the following dimensions:

1. Rhetoric
2. Specs
3. Test suites
4. Implementations.

Given point (1) in that list, I'm finding it difficult to correlate with your complaint of lack of objectivity in others.


What scenario do you forsee causing it to be so utterly difficult to add other schemes well ahead of WebID actually gaining traction?

I never said or inferred that. Quite the contrary i.e., I am asking: what's so difficult about keeping WebID URI scheme agnostic from the get go? 

It's really really really simple, and I've now explained it fully five times.

>From a user's perspective, anything they have called “a WebID” must work with any site claiming to accept “a WebID” for authn, consistently.  It's a contract, of sorts: call it a usability contract if you like.

It's fine to support FTP. Or WebFinger. Or WHOIS. It really doesn't matter, but there are consequences in doing so, chiefly that once it's baked in, certificates containing those schemes will be issued, and users will then expect them to work across the board. You can't simply say “it must be universal!” because there isn't a single decentralised mechanism for resolving _any_ given URI into a resource.

You yourself gave a key example of this right at the beginning of the thread: you had certificates with unsupported schemes, and they didn't work. You were confused as a result, and thought there was a bug. You're a smart, experienced, technically-savvy user — how's my grandmother going to cope with that situation?

You can build agnosticism for the sake of future-proofing into the spec, and indeed Henry has said _repeatedly_ that this is the case, and not one single person is arguing otherwise, but in order to actually produce something which *isn't* Dead on Delivery, you need to specify what schemes are actually expected to WORK.

M.

-- 
Mo McRoberts - Data Analyst - Digital Public Space,
Zone 1.08, BBC Scotland, 40 Pacific Quay, Glasgow G51 1DA,
Room 7066, BBC Television Centre, London W12 7RJ,
0141 422 6036 (Internal: 01-26036) - PGP key 0x663E2B4A

http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.