Re: self-signed

On 4/19/11 5:01 PM, Mo McRoberts 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?
>
> >From my personal perspective, from my understanding of WebID (and 
> from the point of view of the project I work on and whether WebID can 
> be a part of it), this situation simply shouldn't be something which 
> arises outside of experimental environments.
>
>
> > It isn't so simple when the protocols in use are ambiguous about 
> their essence. To me, URI agnosticism
> > is crucial re. WebID viability. Any task that negates this is 
> broken. Again, that doesn't mean every
> > implementation has to support multiple schemes, it simply means that 
> on implementation should
> > make a scheme specific fatal fault assertion about a Cert. based on 
> the scheme of the WebID that
> > it bears. Indicating an inability to understand the scheme of the 
> WebID is much better than inferring
> >  that the WebID is invalid.
>
> A failure's a failure from an end-user's perspective. The "why" is 
> only important if you understand enough to diagnose. Indicating an 
> inability to understand the scheme of the WebID is _only_ better than 
> inferring that the WebID is invalid if you're a developer, for the 
> most part. In either case, the damned thing doesn't work, the tech's 
> rendered worthless.
>

The UX is layered. There are implementation layers in place before this 
tech manifest in Grandma's usage realm. WebID won't make it to Grandma 
in any capacity if its bootstrap plan is broken. Even worse, an inferior 
alternative captures Grandma and compromises her privacy on an 
exponential scale per InterWeb packet that she produces or consumes. 
Basically, collective nightmare scenario for anyone that cares deeply 
about WebID.

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