Re: self-signed

On 4/19/11 1:37 PM, Mo McRoberts wrote:
>
> 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.
>

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 :-(
>
>
> Given this, there is nothing precluding (nor has there ever been, 
> AFAIK!) a subsequent revision adding "acct:" or "mailto:" schemes to 
> this list.
>

See comment above.

>
> 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.
>

It logically won't matter, there won't be many people concerned about it 
at all. As I said, the whole concept would be DoD by that time. In my 
eyes, from my experience, DoD == where RDF is right now, ditto Semantic 
Web religion.

I don't want WebID in the same bucket, the issue at hand it just way too 
important. The world needs a fix for the Identity flaw that pervades the 
InterWeb. It needs a solution that has low activation threshold.

It isn't about programmers and code. It's about architecture derived 
from core concepts such as:

1. Object Identity and Representation Distinction
2. Name based Indirection (de-reference or indirection operator 
functionality)
3. Data Addresses (address-of operator functionality)
4. Data Model
5. Logic based Conceptual Schema that constrains Data Model (re. #4).

HTTP is a low cost route to all of the above as demonstrated by Linked 
Data. That doesn't mean its the only way. It's just an option. There are 
other routes to 1-5. You don't need to have these alternatives 
functional by everyone, simply espouse the architectural purity of real 
openness at every turn.

Note: by "turn" I am not implying "code". This is about the very big 
picture into which WebID potentially fits.


Kingsley
>
>
> 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. 


-- 

Regards,

Kingsley Idehen	
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen