Re: self-signed

On 19 April 2011 23:01, Mo McRoberts <Mo.McRoberts@bbc.co.uk> wrote:
>
> On 19 Apr 2011, at 21:49, Kingsley Idehen wrote:
>
>> On 4/19/11 4:14 PM, Mo McRoberts wrote:
>>> 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?
>
>> Which is why implementers should deliver clear messages when they hit
>> faults related to a URI that
>> serve as WebID in a Cert.. That's basically the essence of the matter.
>> This issue is a few steps away
>> from grandma as she shouldn't really care about such details.  Not caring
>> doesn't mean HTTP scheme
>> specificity couldn't adversely affect her ability to control her own
>> vulnerability (privacy) in cyberspace,
>> at the very least.
>
> Okay then — excuse my ignorance — please outline to me, how _exactly_ it
> will work when:
>
> a) Grandma has a "WebID" certificate containing only a SAN with a mailto:
> URI
>
> and
>
> b) the server (with a "Log in with your WebID!” button) only supports http:
> and https: URIs
>
> What *exactly* do you think should happen in this instance?

It shouldn't come to that. Where did Grandma get her mailto:-based
WebID? Can we discourage the provider from this practice without
saying "it's not WebID"? Can we write the spec in a way that
discourages people from pushing out such things to non-technical users
before there are enough consumers?

Some version of http://en.wikipedia.org/wiki/Robustness_principle "Be
conservative in what you send; be liberal in what you accept."

So consumers MUST understand http/https, MAY understand others;
publishers/providers SHOULD [your words here] ...?

Dan

Received on Tuesday, 19 April 2011 21:18:14 UTC