W3C home > Mailing lists > Public > public-xg-webid@w3.org > April 2011

Re: self-signed

From: Nathan <nathan@webr3.org>
Date: Tue, 19 Apr 2011 20:13:46 +0100
Message-ID: <4DADDEEA.3010908@webr3.org>
To: Mo McRoberts <Mo.McRoberts@bbc.co.uk>
CC: Kingsley Idehen <kidehen@openlinksw.com>, public-xg-webid@w3.org
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…

I read anonymous user to be not authed, the default state, as in nothing 
happened, you're not logged in so you'll be asked to try again or for 
some other form of id. Rather than you'll be authed with no auth 
details. Perhaps just needs the text clarified a little.

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

Not really, it just means you don't know, does HTTP the protocol specify 
that only the methods GET DELETE OPTIONS POST PUT can be used? No, it 
simply defines what they and places some practical limitations on the 
syntax of any other method names somebody may want to define or use.

We can take the same approach, MUST be a URI, that's enough.

Remembering that this is just in regards to what a valid WebID is, 
syntax-wise, if it's a valid IRI it's a valid WebID, that doesn't mean 
it'll lead to a valid authentication with webid protocol though, just 
like having an http scheme uri on a bit of paper doesn't mean it'll be 
dereferencable when you pop it in a browser.

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

Why? the protocol itself will determine when an authentication attempt 
is successful or not, having an unknown or unsupported IRI is just 
another authentication failure state, and that's true of all IRIs, 
http:// ones or foobar:// ones.

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

Yes as you say it's essentially the same thing, it's an authentication 
failure, no need to limit what a WebID is beyond saying "a valid IRI" - 
we gain nothing at all by adding such a constraint.


Received on Tuesday, 19 April 2011 19:14:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:44 UTC