Re: self-signed

On 4/19/11 3:13 PM, Nathan wrote:
> 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.

+1000

Kingsley
>
> 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.
>
> Best,
>
> Nathan
>
>


-- 

Regards,

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

Received on Tuesday, 19 April 2011 19:47:21 UTC