- From: Henry Story <henry.story@bblfish.net>
- Date: Tue, 19 Apr 2011 23:31:45 +0200
- To: Dan Brickley <danbri@danbri.org>
- Cc: Mo McRoberts <Mo.McRoberts@bbc.co.uk>, Kingsley Idehen <kidehen@openlinksw.com>, public-xg-webid@w3.org
On 19 Apr 2011, at 23:17, Dan Brickley wrote: >> >> 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] ...? +1 Agree on this. I think we have finally found a real solid use case for ISSUE-1: Multiple URI entries in the SAN extension A good Certificate provider should put a WebID using the most widely deployed scheme available, whenever thinking of using a less well known scheme. That way older servers will have the chance to authenticate the person as well as any newer ones that can use the new schemes Henry (I know I was meant to go to bed a while ago, but somehow...) Social Web Architect http://bblfish.net/
Received on Tuesday, 19 April 2011 21:32:17 UTC