RE: self-signed

On 19 Apr 2011, at 17:21, Kingsley Idehen wrote:

> To quote Henry re. my initial question, stated as follows:  "What happens when the SAN URI (WebID) isn't "http:" scheme
> based? That's a critical test.
>
> Henry: "If the server does not know how to deal with it, the user is anonymous. In the tests we should have a way for
> the server to tell that he does not know how to deal with a URI type." .

An “anonymous” user isn't generally useful; the default state is anonymous, and still being anonymous after you've logged in means you've confusingly performed some action and be no better off as a result…

> Not knowing how to deal with URI type (scheme) != a valid or invalid WebID.

If not “invalid” then WebID certificates using different schemes would behave differently on different servers, with no clear (to the user) reason why...

> Today, code is emerging that takes the view that WebIDs that aren't HTTP scheme based == invalid.

My own view (on the basis of the above) is that this is what the eventual spec should say, but this is a specific issue which needs to be settled upon in its own right (and not rolled up into other things).

> This whole thread started because I have a massive collection of Certs. carrying different variations of Identifiers in
> different slots. Thus, you can imagine what happened to me when I randomly did some testing only to assume bugs
> had crept into our code, initially. Then instinctively picking an HTTP scheme based WebID to see if it made a
> difference, which it did etc..

This is in part a UI issue… Consider if there was a mechanism by which a server can indicate to a browser “only offer choices to the user which are WebID certificates” — I know I don't want to have to mentally discard my BBC internal certificates, my MobileMe iChat certificate, and my iPhone Configuration Utility certificate (none of which are useful in a WebID context, and neither would I particularly want them to be) when I'm being presented with a certificate-selection interface on a WebID-supporting site.

Let us say for the sake of example that the basic definition of the WebID is:

An X.509v3 certificate with a subjectAlternativeName containing the URI of your identity; this identity can be resolved by some means to a FOAF document containing the public key of that certificate.

_And also that_:

A “version 0.1” [or whatever] WebID must include an always include an “http” or “https” URI in the SAN field.

Given this, there is nothing precluding (nor has there ever been, AFAIK!) a subsequent revision adding “acct:” or “mailto:” schemes to this list.

So the question is “when presented with a certificate which doesn't conform to that [version 0.1 WebID, or whatever it ends up being called], what should a server do?” — and that might be because “no supported schemes are present in the SAN” or it might be “there is no SAN at all”, essentially it amounts to the same thing.

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.